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Amiről nem tudunk, 
a2 nincs? 


Mint tudjuk, az Active Directory DNS alapokon nyugszik. Mégpedig a 
forward lookup zóna megfelelő bejegyzésein. Aki nem adja meg az AD- 
nak, ami DNS-ügyben jár neki, az elveszít mindent, a címtár nemhogy 
kívülről nem érhető el, de önmagát sem találja meg. Ez idáig triviális. 


De mire való a reverse lookup zóna? Tehát az a zónatípus, amelyik nem név-31IP, hanem 
pontosan fordítva, IP-snév feloldást végez. (Ennek a ,névfeloldásnak" az alapja az in- 
addr.arpa zóna alá felvett, az IP-címből képzett zónában található PTR record.) Ha jól meg- 
vizsgáljuk a Windows működését, azt tapasztaljuk, hogy erre semi szükség. Nincs olyan 
Windows-komponens, amelyik revesre lookup lekérdezést végezne. Ebből a tapasztalatból 
kiindulva magam is hangoztattam, hogy reverse lookup zónára nincs szükség, tehát ne is 
fárasszuk magunkat annak létrehozásával. 


De nemrégiben rájöttem, hogy ez a gyakorlat milyen súlyos biztonsági problémához vezet. 
Tűzfal ide-tűzfal oda az összes Windows-munkaállomás neve és belső IP-címe publikálás- 
ra kerül az Internet felé! Ebből az adathalmazból pedig fantasztikusan pontos hálózattérké- 
peket készíthetnek arra illetéktelen személyek. Tudni fogják mind a munkaállomások, mind 
a kiszolgálók nevét, és belső IP-címét. Mindez azért van így, mert a Windows 2000 és utó- 
dai (XP, YP, 2003, Longhorn, 3000) IP-cím felvételkor és változáskor, valamint újraindulás- 
kor alapértelmezésben kibocsátanak magukból egy (-két) dinamkus DNS kérést, hogy a 
DNS Server regisztrálja be a zónafájlba az új IP-címüket. Valójában két DDNS-kérés indul 
el a hálón: egy forward és egy reverse. (Mégegyszer emlékeztetőül: a forward névhez ren- 
del IP-t, míg a reverse: IP-hez rendel nevet.) 


A forward DDNS általában célt ér, és befut a céges DNS Server megfelelő zónájába. A 
reverse DDNS azonban (hisz nincs is ilyen zónánk) a szokásos (rekurzív) módon kimegy a 
root name serverekhez, onnan az arpa-hoz, onnan az in-addr.arpa-hoz stb. És mit tartal- 
maz? Hogy a 172.16.12.12 cím a MARI NENI GEPE című hoszthoz tartozik. Idővel, szép 
fokozatosan minden PC neve és IP-címe kikerül a netre! Ez azt hiszem, eléggé kellemetlen 
mellékhatás ahhoz, hogy elgondolkodjunk a megfelelő reverse DNS zóna létrehozásán. És 
azt is javaslom, hogy aki korábban azt hangoztatta, hogy ilyen zóna nem kell, azt dobáljuk 
meg záptojással és paradicsommal. Tehát engem. 


Kimértem Network Monitorral is, vajon pontosan hová igyekeznek a belső IP-címeket (70, 
172 és 192) tartalmazó reverse lookup DDNS-utasítások. Börtönbe. Az elutasító választ a 
prisoner.iana.org cím adja. 


Fóti Marcell 
MCT 
marcellfőnetacademia.net 
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Scripting a gyakorlatban gyímobyss 

800 számítógép átvizsgálása fél nap alatt 

Egy hazai nagyvállalatánál jelenleg térnek át a munkaállomásokon NT4-ről Windows XP- 
re. A teljes újrainstallálás mellett döntenek, hogy az NT4-ben hat év alatt felgyülemlett 
szemét ne koszolja össze a friss operációs rendszert. Biztosra megyünk: a C:N formázásá- 
val garantáltan eltűnik az NT4 — de a felhasználók adatai is. Azokat tehát előbb le kell 
menteni. De hol tárolják a dokumentumaikat? Ezt kellene gyorsan és biztosan kideríteni! 
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Rendszerfelügyelet nagyvállalati környezetben 


Avagy a dromedár szemfüle 


Ahogyan az informatika egyre nagyobb teret követel magának a vállalati kör- 
nyezetben, úgy egyre komplexebbé válnak a rendszerek, egyre nagyobb ren- 
delkezésre állást követelnek meg tőle, így egyre nagyobb az igény a rendszer 
állapotának nyomonkövetésére. A rendszerfelügyelet itt nyújt hathatós segít- 
séget az üzemeltetés részére. 





byágyszeresdnbaz  ESSEETszzmezzezzea 


Windows 2000 Server Resource Kit V. H- 


Folytassuk tovább kisebb-nagyobb hálózati segédprogramokkal. 


Io test for nanes Cin nanes.txt) againat WINS ververs Cin servera.txt? 
I cieck versígn nunber co meleg 

6 nanitor VINSE and detmc jé 

T6 varáfy replícarion conf íg setüp 








1e tegyle the internetíve svíteh (current value: Interactive; 
Ta exit thísr tool. 
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mg A Windows 2003 TLP/IP-implementációja 


"a" állomás [új -bejegyzés ööö jé 4 sa; 
"álom SB gaz Ed ezzásdása A TCP/IP-verem felépítése és főbb funkciói 





1 BH ARP-kérés küldése 









"B" állomás jó 
S 


JE Feföbejegyzés hozzáadása 


A DHLP rejtett szépségei — DU. 


A címkiosztó szolgáltatás üzembehelyezésekor különösen fontos jól 
megválasztani a helyszínt. Egyszerű környezetben, ha nincs is több te- 
lephely, ez nem probléma, ma azonban már egyre több összetett háló- 

zat működik. Lehet a topológia bármilyen bonyolult, a DHCP szerve- 
reknek megfelelően kell működniük. 


A TCP/IP az Internet működésének alapja, és mára a vállalati hálózatok- 
ban is a legnépszerűbb hálózati protokollá vált. Útválasztási funkciói 
maximális rugalmasságot biztosítanak a nagyvállalati hálózatokban is. A 
TCP/IP-verem megvalósítása és szolgáltatásai tehát döntő fontosságúak 
minden operációs rendszer hálózati funkcióinak felépítésében. 


( 
tea Dynamic Host Configuration Protocol (DHCP) Interface 





Hop-count threshold: 4 -] 
Boot threshold (seconds): 4 2 
3 ig 


EZ őő Active Directory Application Mode 


ra 06000 


p— eme 7 ÉSS köz kammömmány Címtárat mindenkinek! 
és Az ADAM használatával többé nincs szükség egyedi 
Te -gg- É 71 címtárszolgáltatásra speciális, esetleg belső fejlesztésű alkalma- 
fi TET zásaink számára sem, mivel az ADAM messzemenően képes alkalmaz- 
d: úlsggáó kodni bármilyen feladathoz. Minden ezt igénylő alkalmazás önálló, de az 





Active Directory-val együttműködő címtárat használhat egyedi sémával és 
replikációs beállításokkal. 


Tanúsítványkiadók a Windowsban S27e e 
Kulcsarchiválás és helyreállítás, adatmentés, ! 
Certificate Trust List 











A Windows Server 2003, Enterprise Edition tanúsítványkiadó szolgáltatása se- ke 
gítségével biztonságosan tárolhatók és szükség esetén vissza is tölthetők a fel- ém 
használók privát kulcsai. Cikkünkben kitérünk még a tanúsítványkiadó adat- k 
bázisának biztonsági mentésére, valamint a tanúsítványláncok összekapcsolá- e. 
sának egyik módjára. a 

m 
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öezálonemtsom tázolhoimtet Háromlábú ISA Server 


Redrect HTTP tegvesta az 


BEEE S zetÉe DMZ külön hálózaton 

ker zestet Amikor egy cég ,magához ragadja" az Internetes szolgáltatások körét, és saját SMTP, 

ZENE ELÉ, EKET; HTTP és egyéb kiszolgálókat üzemeltet, mindig felmerül az a nem is egyszerű tervezési 

€ Frog kérdés, hogy hova tegyük a kiszolgálókat? A belső hálózatra, és onnan publikáljuk? Ez a 
Terád jeget Köndpajltnáktátás ] jelenlegi, férges korszakban veszélyes lehet. Két tűzfal közötti DMZ-be? De hisz az plusz 


FA a. a 
egy vasat igényel! Vagy netán használjuk a háromlábú modellt? Miért ne? 


r T 
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egbztató szolamatos] 


























Biztonságos aláírás kezelő alkalmazás készítése U. 
Az aláírás-ellenőrző alkalmazás 


Az előző részben az aláírás kezelő alkalmazás adatai, valamint az aláírás létrehozó al- 
kalmazás ezeket hasznosító komponensei, s az ezekkel szemben támasztott követel- 
mények lettek ismertetve. Most az aláírás-ellenőrző alkalmazást mutatjuk be hasonló- 
képpen. Ezzel nagy ívű sorozatunk egyben a végére is ér. Bár nem fért bele részletesen 
minden, a lényeget sikerült belegyömöszölni. Aki a leírtakat magáévá tudta tenni bát- 
ran nekivághat egy aláírás kezelő alkalmazás fejlesztésének vagy bevezetésének. 
















































































Vírtuallogi — Vírtualtog2 —— Mrtuallog3 — Virtuallog4 — Virtvallog 5 dé 7! s 4 
va A tranzakciónapló és környéke 
Tancatd Ta 1 1 SOL Server 2000 adat- és tranzakciónapló-fáj- 
EE Tlog örpcint FL og lok, adatbázis helyreállítási modellek, mentési 
stratégiák 


Az adatok rendszeres mentésének fontosságát mindenki tudja. Arról már olykor elfeledkezünk, hogy felmérjük, mennyi tranzak- 
ció (új adat, vagy módosítás) elvesztését tudjuk elviselni. Az SOL Server tranzakciónaplóját sok rendszergazda ;,nem szereti". 
Gyakori kérdés, miért nem lehet a tranzakciónaplót kikapcsolni? Meglepően sok adatbázis , simple" helyreállítási modellben 
működik, ami a tranzakciónapló automatikus ürítésével jár. Ez (többnyire) megakadályozza, hogy a logfájl nagyra nőjön, de 
ugyanakkor lemezhiba, vagy egy véletlen táblatörlés után lehetetlenné teszi az utolsó pillanatig érvényes helyreállítást. 
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Egy hazai nagyvállalatánál jelenleg térnek át a munkaállomásokon NT4-ről Windows XP-re. A teljes 
újrainstallálás mellett döntenek, hogy az NT4-ben hat év alatt felgyülemlett szemét ne koszolja össze 
a friss operációs rendszert. Biztosra megyünk: a C:N formázásával garantáltan eltűnik az NT4 — de a 
felhasználók adatai is. Azokat tehát előbb le kell menteni. De hol tárolják a dokumentumaikat? Ezt kel- 


lene gyorsan és biztosan kideríteni! 


A feladat tehát egy olyan lista készítése, amely minden létező 
helyről tartalmazza a felhasználó adatait, még akkor is, ha az el- 
múlt hat évben a SYSTEM32 könyvtárba mentett. Szélsőséges 
példa az a felhasználó is, aki minden könyvtárának úgy adott 
nevet, hogy belecsapott a billentyűzetbe. Így lett adatainak 
főkönyvtára az ,asdfasd", alatta pedig rendre ,dígsíe" és 
.gwegwe" könyvtárakat találunk. 

A feladat elvégzéséhez valamilyen leltárra volna szükségünk, de 
egy olyan okos leltárra, ami az ál-dokumentumokat (eula.doc és 
társai) nem tartalmazza. Szintén nem kell a dokumentum, ha a 
kukában, vagy más lehetetlen helyen tanyázik. S ha már meg- 
vannak, következő lépésben másoljuk is át őket a D:N meghaj- 
tóra, amit nem fogunk megformázni. Ott biztonságban lesznek 
a frissítés alatt is. 

Ez utóbbi, tehát a mentési igény kapásból kiüti a kezünkből a 
hagyományos rendszerfelügyeleti eszközöket, mert leltárt készí- 
teni még tudnak, még arra is képesek, hogy a hamis dokumen- 
tumokat kiszűrjék, de ezek lokális lementésére önmagukban 
már nem képesek. Ahhoz már valami kiegészítő alkalmazás 
szükséges. 


Hagyományos eszközökkel kísérletezünk 


Első megközelítésben kipróbálhatjuk, mit tud maga a jó öreg 
DIR parancs. Megadja a feleletet, hol bújnak meg a dokumentu- 
mok? Próbáljuk ki ezt: 


DIR $.DOC /S 


Igen, igen, de az eredmény nem kielégítő, hanem inkább ször- 
nyű. Jártunk a kukában, kilistáztuk az összes winword.doc-ot 
(most derül csak ki, hogy hány tucatszor van fenn a gépen), ki- 
listáztuk a Windows mélyén megbúvó dokumentumokat, egy- 
szóval kaptunk egy vödör kacatot. Jó lenne, ha a DIR-nek meg 
tudnánk adni egy kivétellistát, hogy mit NE vegyen figyelembe. 
Ilyet sajnos az öreg jószág nem tud. 


A fejlesztés első lépése: v0.82 — megszólal az FSO 


Akinek kalapácsa van, mindent szögnek néz — mondja a régi kí- 
nai bölcselet. Aki tud scriptet írni, minden problémát azzal old 
meg. Ha a gyári DIR nem tudja lekezelni a kivételeket, majd a 
saját kézzel fejlesztett DURR.VBS megoldja a problémát. Dir- 
durr. 

Döntés született tehát a DURR.VBS kifejlesztéséről, ami a DIR 
belső parancs utódja lesz. Ha készen van, könnyedén bele lehet 
fejleszteni a mentési képességet is. 

Hogyan kezdjünk hozzá? A Windows Scripting Host rendszer- 
ben a FileSystemObject alkalmas a lemezen lévő adatok mani- 


pulálására. Tekintsük át röviden, milyen objektumokból áll ez az 
objektumtár? A következő ábra szemléletesen összefoglalja, mi- 
lyen hierarchiában érhetők el a lemezen tárolt adatok. Ennek 
megfelelő objektumhierarchiát tartalmaz a FileSystemObject, 
emiatt nagyon kényelmes lesz majd a használata. Vágjunk is be- 
le, írjuk meg a DURR.VBS-t, mely kilistázza a dokumentumokat 
a merevlemezről! Ehhez a funkcióhoz több lépésben jutunk el, 
először elégedjünk meg azzal, hogy egyáltalán szóra bírjuk a 
rendszert. 


FileSystemObject 





E A FileSystemObject objektumcsalád 


Az alábbi kód kilistázza a C:N meghajtó gyökerében található 
mappák neveit. 


1. option explicit 

2. dím oFSO, oDrive, oFolder 

3. set OFSO - 
Wereateobject("scripting.filesystemobject") 

4. set oDrive - oFSO.GetDrive("C:N") 

5. for each oFolder in 
"StoDrive.RootFOlder.Subfolders 

6. wscript.echo oFolder.Name 

7. next 


Magyarázat: 

1. Az első sor szerepe, hogy egyszer s mindenkorra kizár- 
juk a deklarálatlan változók használatát. Ez feltétlenül 
szükséges, így ugyanis elejét vehetjük, hogy a 
,levegőből" képződjenek üres változók (félregépelések 
folytán). 

2. A második sorban deklaráljuk a felhasználni kívánt vál- 
tozókat. Adattípust nem adunk meg, mert olyan a 


VBScriptben nincs. Minden változó Variant típusú. Ami 
a változóneveket illeti, roppant tudományosan néz ki az 
oDrive és az oFSO, de a valóságban ezek tetszőleges 
változónevek. Éppenséggel kutyulinak is hívhatnánk a 
mappaobjektumot. Abból aztán olyan kód keletkezne, 
amit két hét távlatából mi magunk sem lennénk képesek 
értelmezni. Ezért adtam a változóknak funkcionális ne- 
vet. A nevek elején az ,o" hangocska pedig Simonyi Ká- 
roly (Microsoft) találmánya, ezt hívják magyar jelölésnek 
(hungarian notation). Az a szerepe, hogy egy pillantás 
alatt felismerjük a változó típusát (o—objektum). Ez külö- 
nösen hasznos a VBScript nyelvben, ahol nincsenek is 
valódi adattípusok. 

3. Létrehozunk egy Scripting.FileSystemObject objektu- 
mot, melynek kezelőjét beletöltjük az oFSO változóba. 
A későbbiekben ennél a , nyélnél" fogva lehet őt rángat- 
ni. 

4. Az oDrive változóba kerül a C:N meghajtóobjektum. En- 
nek gyökérkönyvtárán keresztül vezet az út le a mappá- 
kig, fájlokig. 


Az 5-6-7. lépésben ciklusban kiíratjuk a meghajtó gyökérkönyv- 
tára alatti alkönyvtárak nevét. Az eredmény így néz ki 
(cscript.exe futtatómotor használatával): 


TES k s 











E A DURR.VBS 0.82-es verziója kilistázta a gyökérkönyv- 
tár alkönyvtárait 


Ez megvolt, jöhet a következő lépés: a teljes könyvtárstruktúra 
bejárása. 


DURR.VBS v0.85 - könyvtárfa bejárása 


Tetszőleges mélységű faszerkezetek bejárására rekurzív függ- 
vényhívást használhatunk. A függvény elvégzi feladatát azon a 
könyvtáron, ahol éppen áll, majd meghívja önmagát a gyermek- 
könyvtárainak átadásával. A vO.82-es kódon tehát változtatnunk 
kell: a könyvtárnév-kiírási feladatot egy olyan függvénybe vagy 
eljárásba helyezzük át, ami nem mellesleg meghívja önmagát - 
saját gyermekeinek lekezelésére. Ez a kód így néz ki (az első 
négy sor ugyanaz, ezt nem ismétlem meg): 





A főprogram ötödik sora ebben a változatban már csak meghív 
egy eljárást, és minden feladatot arra bíz. A szubrutin neve: 
konyvtarlistazo, és két bemeneti paramétere van. Elsőként azt a 


tech.net ver iát 


könyvtárobjektumot kell átadni neki, amelyikkel fog- 
lalkoznia kell, másodikként pedig egy szintszámlálót 
kap, amit a könyvtárfa kiírásánál használok fel a lista 
gyönyörűbbé tételére: minden alkönyvtár egy szóköz- 
Zel beljebb kerül, mint a szülője. 

A nyolcadik sorban kiírom a képernyőre az aktuális mappa ne- 
vét (beljebbtolva a gyári space() függvényt által visszaadott da- 
rabszámú szóközzel). A 9-11. sorban a szubrutin rekurzív meg- 
hívását láthatjuk: minden alkönyvtárára ráeresztjük ugyanezt az 
eljárást. A rekurzió addig hatol lefelé, amíg talál alkönyvtárakat. 
Futtassuk! Ha átadhatnám, milyen vizuális élményt nyújt, aho- 
gyan ez a nyúlfarknyi script bejárja az egész C:V meghajtót! 
Csak gördül, gördül felfelé a sok-sok könyvtárnév! Gyönyörű! 
Naphosszat elnézném, de hopp, elszállt! 


MLS t s ke 
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E DURR.VBS vO.85. Jogosultsági hiba miatt elszállt 


Úgy tűnik, hibakezelés nélkül nem lehet bejárni egy partíciót. 
Az új verzióban már ez is benne lesz! 


DURR.VBS v0O.93 - némi hibakezelés 


A VBScript igen ostoba hibakezelési lehetőséggel rendelkezik, 
de céljainknak megfelel. Minden kritikus programsor elé be kell 
írni, hogy ,ON ERROR RESUME NEXT", ennek hatására hiba 
esetén sem szakad meg a programocska futása. A hiba kódja be- 
kerül az erre a célra létrehozott Err objektum Number tagválto- 
zójába, amit a kritikus kódrészt követően azonnal illik megvizs- 
gálni, vajon történt-e valami galiba? 

A hibaüzenet tanúsága szerint a tizedik sor nem tudott lefutni, 
vagyis a mappa gyermekeit nem sikerült kilistázni. Ezt a részt ve- 
gyük körbe hibakezeléssel! 





Fáradozásunkat siker koronázta, a script végigfut a teljes partí- 
ción. Igaz, hogy egyelőre csak a jogosultság hiányából fakadó 
hibákat kezeltük le, de egyelőre nem is találkoztunk más hibá- 
val. A világ összes hibájára ne próbáljunk azonnali megoldást 
találni. 5 

Most már lassan jöhetne a tényleges munkavégzés, a hasznos 
dokumentumok megtalálása. A könyvtár nevének kiírása tájékán 
kellene meghívni egy másik eljárást, vagy függvényt ami az 
adott könyvtárból kiválogatja a hasznos fájlokat. Legyen a neve 
fajlvalogato! 
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DURR.VBS v0O.97 - fájlok feldolgozása 


Gondolkozzunk egy kicsit! Nekünk csak azokkal a 
mappákkal kell foglalkoznunk, amelyekben volt 
hasznos tartalom. E cél elérése érdekében a 
faljvalogatonak függvénynek kellene lennie, hogy 
visszaszólhasson a hívójának, vajon talált-e hasznos dokumen- 
tumot, vagy sem. Vázoljuk fel, hogyan is kellene kinéznie egy 
ilyen függvénynek: 
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function fajlvalogato(oFolder, szint) 
if van hasznos adat then 
fajlvalogato-True 
else 
fajlvalogato-False 
end if 


end function 


Ha találunk hasznos adatot, térjen vissza True (igaz) értékkel, 
ellenkező esetben pedig False (hamis) legyen a válasza. 
Egyetlen dolgot nem határoztunk még meg: mitől hasznos egy 
adatfájl? Első közelítésben mondjuk akkor hasznos, ha a kiter- 
jesztése .DOC. A ".DOC kiválogató függvény így nézne ki: 


function fajlvalogato(oFolder, 
dim oFile 
fajlvalogato-False 
for each oFile in oFolder.Files 
if lcase(right(oFile.Name, 3)) - 
REM ti HASZNOS ADAT! ttt 
wscript.echo space(szintt1) 
fajlvalogato-True 
end if 
next 
end function 


szint) 


"doc" then 


§ oFile.Name 


Ha ezt meghívjuk a konyvtarlistazo eljárás legelső sorában úgy, 
hogy csak akkor írja ki a könyvtárneveket, ha azokban docot is 
talált... 


if (fajlvalogato(oFolder, szint)) then 
wscript.echo space(szint) £ oFolder.Name 


end if 


máris intelligensebb kódunk van, mint a DIR parancs. 
Mindössze annyi benne a ,baki", hogy előbb írja ki a fájlneve- 
ket, és csak azután a könyvtárat, de kit zavar? És még csak a 
0.97-es verziónál járunk! 

Lefuttatva a legújabb verziót, meglepetéssel tapasztalhatjuk, 
hogy winword.doc mindenhol van: 








Hová lett az üres hely a lemezen? Megette a 
winword.doc! 


Sajnos a jelenlegi kód nem írja ki a könyvtárak teljes elérési út- 
vonalát, így sötétben tapogatózunk, hol is tanyázhat ez a sok 
winword.doc, de szerencsére a Folder objektumnak van egy 
Path tagváltozója is. Ha kicseréljük az eredeti könyvtárnév-kiíra- 
tó sort 


85 wscript.echo space(szint) § oFolder.Name 
erre: 
8. wscript.echo space(szint) £ oFolder.Path 


mindjárt láthatjuk is, hol bujkál ez a rengeteg , hasznos" adat. 
Szanaszét a profilkönyvtárakban! 


sMAdninistratorMenplates 
tor.NETACADEMIANTenplates 
CTZTON TES ESZ 


EZT TA zását e eááa 


SettingsvfnXTenplate 


FONz ej JON OLTE tÉi 








5 Találtunk néhány winword.doc fájlt a lemezen... 


A következő feladat a hasznos adatok halmazának meghatáro- 
zása. 


DURR.VBS 0.98 - a felesleges elemek kihajítása 


Mint látható, és a cikk elején levezetett gondolatmenetből is ki- 
világlik, kivételeket kell keresnünk, bizonyos dokumentumokat 
ki kell zárnunk a hasznos adatok közül. 

Ehhez jó lenne felsorolni a kivételeket, és valami energiatakaré- 
kos módszerrel összehasonlítani az összes elemet a kivételek lis- 
tájával. Szinte erre a feladatra találták ki a Dictionary (szótár) ob- 
jektumot, ami nem más, mint egy szupertömb (array). Annyiból 
szuper, hogy tudja, milyen elemek vannak benne, és kérdéseink- 
re válaszol is, tehát egymaga elvégzi a kivétellistával való össze- 
vetés nehéz feladatát. 

Kicsit túlságosan is okos, mert nem pusztán értékeket, hanem ér- 
tékpárosokat nyel le, amelyek közül az első a keresett kifejezés 
(szó), a másik pedig a hozzá tartozó szócikk. Általában úgy 
használjuk a szótárakat, hogy a keresett szónál elolvassuk a szó- 
cikket. Nekünk azonban bőven elegendő szolgáltatás egy szó 
megtalálása, szócikként valami random karakterkupacot fogunk 
megadni. 

Nézzünk egy háromsoros példát a használatára! 


set szotar-createobject("scripting.dictionary") 
szotar.add "alma", "az alma egy gyumolcs" 
szotar.add "banan","a banan is egy gyumolcs" 
if szotar.Exists("alma") then 

$ msgbox szotar.item("alma") 


Ez a kis programocska a kételemű szótárból az "alma" szót ke- 
resi, és ha van ilyen, kiírja a hozzátartozó szócikket: 


VBScript 


az alma egy gyumolcs 





Ezt a fantasztikusan egyszerű keresési lehetőséget fogjuk fel- 
használni a nyilvánvalóan értéktelen dokumentumok kiszűré- 
sére. Például így tölthetnénk fel a szótárat a winword.doc-ok 
kiszűréséhez: 


set oSzotarzcereateobject("scripting.dictionary") 
oSzotar.CompareMode - vbTextCompare 

oSzotar.add "winword.doc", "az alma egy gyumolcs" 
osSzotar.add "winword2.doc", "az alma egy gyumolcs" 
oSzotar.add "winword8.doc", "az alma egy gyumolcs" 
A szótárat létrehozása után, de annak üres állapotában a máso- 
dik sorban átállítom kisnagybetű-érzéketlen működésre (case 
insensitive), hogy ne kelljen a fájlneveket állandóan kis- vagy 
nagybetűs formára hozni. 

Figyeljük meg, hogy mivel a szócikkre valójában nincs szüksé- 
günk, oda tetszőleges szöveg kerülhet (választhattam volna rövi- 
debbet is...) 

A szótár feltöltését egyszer, a program elején kell elvégezni, a 
fájlok feldolgozásánál pedig már csak használjuk. Kicsit 
kibővítettem az eredeti if utasítást, hogy magában foglalja a szó- 
tárazást is: 





if lcase(right(oFile.Name, 3)) - "doc" and 
$ not(osSzotar.Exists(oFile.Name)) then 


DURR:VBS vO.99 - a szótár feltöltése fájlból 


Egy kis fantáziával a szótár átalakítható úgy is, hogy egy 
textfájlból olvassa fel a saját aktuális tartalmát, így nem kell a 
scriptbe bedrótozni a kiszűrendő értékeket. Ehhez szintén a 
FilegystemObject . fog segítséget nyújtani, mégpedig 
OpentTextFile és ReadLine metódusaival, a következőképpen: 


set oLista - oFSO.OpenTextFile("kivetel.txt") 

Do While oLista.AtEndofStream cs; True 
oSzotar.Add oLista.ReadLine, "Alma Ata" 

Loop 

oLista.Close 


Az első sorban megnyitjuk a kivetel.txt nevű fájlt. A vállalkozóbb 
kedvűek némi hibakezeléssel is körbeágyazhatják. Ez ebben a 
formában például olyankor száll el, ha nincs kivetel.txt nevű fájl. 
Hát legyen! Én már nagyon unom a hibakezelést! 

Ezután egy ciklussal soronként kiolvassuk belőle a tartalmat, és 
feltöltjük vele a szótárunkat, végül, mivel az illendőség úgy kí- 
vánja, lezárjuk a fájlt. Az , Alma Ata" ne zavarjon senkit, az az 
általunk semmire sem használt szócikk feltöltésére kiagyalt 
string, semmi több. És lassan eljutunk az 1.0-s verzióhoz. Ehhez 
már csak annyit kell hozzátenni, hogy a helyesen megtalált 
fáljokat a script mentse le a D:V meghajtóra, és már készen is va- 
gyunk. 


DURR.VBS v1.0 — a megtalált adatok mentése 


Mentésre használhatnánk a FileSystemObjectben található 
Copy metódust is, viszont kényelmetlen lenne puszta kézzel, 
kódból létrehozni ugyanazt a könyvtárszerkezetet, mint amiben 
a hasznos adatot találtuk. Legyünk ez alkalommal lusták és 
megalkuvók, és használjuk fel az XCOPY parancsot, ami ponto- 
san úgy másol, ahogy arra nekünk szükségünk van. 

Sőt, ha már XCOPY, ne is azonnal hajtsuk végre, hanem inkább 
írjunk a scriptünkkel egy batch fájlt, amiben sorakoznak az 





XCOPY-k. Ennek az az előnye is megvan, hogy a 
DURR.VBS futása után még átnézhetjük, mit is talált 
fontosnak, és ha kell, kitörölhetünk egy-két felesleges 
sort. Persze ezt az utólagos ellenőrzést nem lehet mind 
a 800 gépen megtenni, de a fontosabb helyeken (pl. 
Vezér Elvtárs gépe) igen. 

A batchfájlt a script elején kellene megnyitni, és minden 
egyes hasznos adat megtalálásakor bele kell írni egy újabb 
XCOPY sort. 


set oBatch - oFSO.CreateTextFile("mentes.bat") 


Ez utóbbi kódot oda kell felvenni, ahol megjegyzésben már sze- 
repel, hogy hasznos adatra leltünk, tehát ide: 
REM $ttt HASZNOS ADAT! $ttt 


oBatch.WriteLine "XCOPY " 
S §£ oFile.Name £ "D:N /s" 


oFolder.Path £ "UV" 


És valahol a kód legvégén, amikor már visszatértünk a 
rekurzióból is, le kell zárnunk az oBatch fájlt: 


oBatch.Close 


Összegzés 

Ha valakire olyan feladatot sóznak, amit száz mérnökév alatt le- 
het elvégezni, gondoljon szeretettel a scriptelési lehetőségekre, 
legyen az .NET konzolalkalmazás vagy akár Windows Scripting 
Host-kód. Mindkettőnek megvan a maga előnye és hátránya, de 
egy biztos: csak kóddal sokszorozhatjuk meg önmagunkat. 
Smith ügynök a Matrix2-ben szintén kóddal sokszorozta meg 
önmagát, tanuljunk tőle! 

A DURR.VBS teljes forráskódját a technet weben helyeztem el, 
aki hibát talál benne, kérem jelentse. Nem szégyellem hisz 1.0- 
s változat. Más gyártók szoítvereinek tizenvalahanyadik változa- 
ta is bugos! 


Fóti Marcell 

marcellfönetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


A DURR.VBS 1.0 innen tölthető le: 
(11 http:/technet.netacademia.net/download 


tanfolyamaink: 
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Rendszerfelügyelet 
. nagyvállalati környezetben 


Avagy a dromedár szemfüle 


Ahogyan az informatika egyre nagyobb teret követel magának a vállalati környezetben, úgy egyre 
komplexebbé válnak a rendszerek, egyre nagyobb rendelkezésre állást követelnek meg tőle, így egyre 
nagyobb az igény a rendszer állapotának nyomonkövetésére. A rendszerfelügyelet itt nyújt hathatós se- 


gítséget az üzemeltetés részére. 


Jöttem, láttam, rendszer? 


Amikor az új rendszergazda munkába áll, a lehető legritkább 
esetben kerül egy olyan helyre, ahol éppen most akarnak szá- 
míitástechnikai rendszert bevezetni. A zöldmezős nagy projek- 
tek lassan, de biztosan a ködös múltba vesznek. Helyettük a 
mit is örököltem téma népszerű. 


Kis rendszer — nagy szolgáltatáslista 


Már egy szerényebb informatikai rendszer is sokféle szolgálta- 
tást nyújt. A nagyobb pedig ennek minősített esete. Gondoljuk 
át, mi minden található egy átlagos informatikai rendszerben. 
Szinte minden rendszer része az irodai csomag: 


szövegszerkesztés 

táblázatkezelés 

elektronikus levelezés, fax 

böngészés (igen, az Interneten!) 

naptár- és névjegykezelés, kapcsolattartás 


BBB8BB 


Ez bővül személyre szabott alkalmazásokkal: 
A Ügyviteli rendszer (Személyügy, pénzügy, eszközgaz- 
dálkodás, stb.) 
H Egyéb célalkalmazások (Saját fejlesztések, illetve egyéb 
rendszerek: belső nyilvántartások, elszámolások, illet- 
ve egyéb munkafolyamatokat támogató alkalmazások.) 


Ezekhez a rendszerszolgáltatásokhoz egy általános informati- 
kai hátteret is biztosítani kell, többek között a kiszolgálókkal, 
szerveroldali alkalmazásokkal: 


kiszolgáló operációs rendszer (alapfeladatok) 
irodai szerveralkalmazások 

adatbáziskezelés 

távoli hozzáférés 

ügyviteli rendszer 


BBBBH 


Ha már így együtt vannak, akkor ezt meg is kell(ene) védeni, 
ha jő az ellen: 

TA vírusvédelem 

TA tűzfal 


Ami nem hiányozhat egyetlen rendszerből sem: 
HA mentés 
HA archiválás 


A felhasználószám növekszik, egyre komplexebb, egymással 
kapcsolatban álló alkalmazások kerülnek be a rendszerbe, 
egyre komplexebb igényeket támasztanak a rendszerrel szem- 
ben. (7x24-es üzem, 9x.296 rendelkezésre állás, stb.) Egy szép 
napon nagyvállalati környezetté növi ki magát. 


Az üzemeltetési tapasztalatok szerint a rendszer megbízható- 
sága, sebezhetősége az alábbi körülményektől erősen függ: 
A FELHASZNÁLÓK HASZNÁLJÁK! 

A hackerek feltörik! 

A vírusok elözönlik! 

A mentés behal! 

Az adatbázis elszáll! 

Eljő a kék halál! 

A diszk beadja a kulcsot! 

Az egész géptermet elnyeli a tsunami! 


B8B5BBB8BB 


Ezeknek a rendszereseményeknek valahol nyomuk is marad: 
H Eseménynapló (Event log, ebből mindjárt legalább 3 is 
van egy Windowst futtató gépen) 
A Alkalmazásnapló (minden alkalmazás szorgosan jegy- 
Zetelget, akár sok-sok külön naplóba is.) 
A Forgalmi napló (A Webkiszolgáló, a tűzfal és társai íro- 
gatják.) É 
A Teljesítménynapló 
A Vírusvédelmi rendszer írásai (Érdekes olvasmány!) 
A Egyéb cnagyonsajátfontosz rendszer állományai 
Ezek mérete már egy közepesen fejlett rendszer esetén is egy- 
re inkább túlmutat a Háború és béke terjedelmén. (Több tíz- 
ezer soros, megabájtos szöveges naplók képződnek naponta.) 
Teljes átolvasásuk egyre kevésbé képzelhető el, elsősorban a 
lassú humán periféria korlátai miatt. (A régi gondolatra, hogy 
majd csak a piros részekre koncentrálunk, a válasz: , Nem 
minden hiba piros, és nem minden piros hiba", aztán meg a 
szöveges naplókat nem is színezik.) 
A rendszerüzemeltetés munkája — ahol lelkiismeretesen vég- 
zik -— itt az egekig ér. 
Olyan ez, mint amikor Gizi néni rohan a kis falusi állomáson 
a biciklit tolva a vonat után, de nincs ideje felülni a biciklire, 
mert akkor lekési a vonatot. 


Értesítések 


A rendszer különféle komponensei állapotukról néha üzenetet 
is tudnak küldeni (pl.: Exchange, IIS stb.), de ez sem olyan 






É. 
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nagy öröm. Mi lenne, ha üzengetés helyett inkább meggyógyí- 
taná önmagát? 


Komponensek felügyelete 
A napi felügyeleti kézimunka megkönnyítésére már eddig is 
léteztek különféle rendszerek, melyekkel egy-egy részfelada- 
tot megoldhattunk: 
HA Eseménynapló szűrése, keresés 
Az eseménynaplóban minden feljegyzést megtalálha- 
tunk -— amit a rendszer jónak látott közölni velünk. 
Ezekben nem is olyan nagyon könnyű eligazodni, még 
az eseménynapló szűrő és keresési lehetőségeivel sem. 


atai 











[7] Sikeres események naplózása 
[7] Sikertelen események naplózása 
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Figyelmeztetés 
v] Hiba 

















I 
I 
Eseményforrás: (Mind) Ea 
Kategória (Mind) Ka ! 
Eseményazonosító ] 
Felhasználó: ! 
Számítógép: 
Ettől: Első esemény Kg ! 


Eddig: — Legutóbbi esemény [77 
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E Az eseménynapló szűrő és keresési lehetőségei 


A Beépített teljesítménymonitorozó eszközök: Perfmon: 
Az operációs rendszer, illetve számos alkalmazás kü- 
lönféle paraméterei figyelhetők meg akár élőben, vagy 
bizonyos időszak eseményei menthetők el későbbi 
kiértékelésre. 

IMA A Notepad 
Elsősorban a szöveges naplóállományok megtekintésé- 
re használható. Különösen problémás a nagy állomá- 
nyok (pl.: ISA log) kezelése, nézegetése. 

B A szerverhardverhez adott monitorozó program (pl.: 
Insight , manager, a HP Proliant kiszolgálók 
rendszermonitorozó programja, ahol a kiszolgálók ál- 
lapota követhető nyomon, illetve sok egyéb információ 
is lekérhető.) 
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TEZAZTKEZS ZET 


E Az Insight Manager képernyői 


Ezek közös hibái: 

8 csak részegységeket látnak (pl.: hardver) 

8 az egyes alkalmazásokat, kiszolgálókat külön-külön 
kell beállítani, nyomon követni 

8 különféle prezentációs réteg (install, beállítások) a kü- 
lönféle alkalmazások különféleképpen jelenítik meg, 
szervezik csoportba az adatokat, ezeket más-más logi- 
ka szerint lehet feldolgozni: 

s Naplóállomány: egyszerűen soronként vannak ben- 
ne az adatok. 

e Eseménynapló: saját formátumú állományban tartal- 
mazza az adatokat 

8 külön adatbázisok -3 összetett lekérdezések ??? 
Ha többféle adat összefüggésére vagyunk kíváncsiak 
(pl.: milyen processzorterhelés volt éppen akkor 
lperfmon], amikor az alkalmazás hibát jelzett lese- 
ménynapló]?) akkor ezt kézzel lekérdezni a különféle 
helyeken, illetve az adatkonverziókat — ha egyáltalán 
lehetséges — elvégezni, az eredményeket egymáshoz 
illeszteni — ha egyáltalán elvégezhető — nagyon nehéz 
munka. 

8 összetett hibák esetén több helyről is érkezik jelzés 
pl.: ha meghibásodik egy hálózati adapter, akkor sok, 
egymással első látásra nem összefüggő hibaüzenetet 
kaphatunk, ráadásul különféle formában: a rendszer- 
naplóban eszközhiba; az Insight managerben hálózati 
eszközhiba; az alkalmazás naplójában: nem éri el az 
adatbázist hiba; stb. 


A gordiuszi csomó 


Minél több komponensből áll egy rendszer, annál több álla- 
potmutatója létezik, sokféle működési jelenséget produkál. 
Egyre fontosabb minél jobban, folyamatosan figyelemmel kí- 
sérni működését, hogy megfelelően, gyorsan, reaktívan lehes- 
sen reagálni, elhárítani a működési rendellenességeket Egyre 
fontosabb proaktívan — már a hibajelenség fellépése előtt — 
megelőző lépéseket tenni a folyamatos zavartalan működés 
fenntartására. 
Ezekhez a feladatokhoz kellene egy eszköz, amely: 

FA Központosított 

FA Önálló egységekből áll 

A Megbízható 

-A Testreszabható 

AA Bővíthető 

JA Biztonságos 
Ez a rendszerfelügyeleti eszköz. 
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A Microsoft termékpalettáján szerepel egy ilyen ter- 
mék: 

A Microsoft Operations Manager (MowM. 

A MoM-ot a NetlO fejlesztette, majd a Microsoft ter- 
mékpalettájára került. Egy olyan rendszerfelügyeleti 


termék, amely sokféle szolgáltatást kínál: 








nm 00 DÍ 





HA Könnyű telepíthetőség (szerveroldalon beszédes tele- 
pítő, a kliensek automatikusan települnek) 

JA Központi, megbízható adatbázis: MS SOL. 

TA Az igényeknek megfelelően skálázható (Akár egyetlen 
MoM szerverrel is elindulhatunk, amit később az igé- 
nyeknek megfelelően tovább bővíthetünk, sőt több 
MoM-ot is összekapcsolhatunk.) 

TA Beépített, házi bejegyzésekkel bővíthető tudásbázis, 

amellyel a begyűjtött információkat értelmezhetjük, a 

hibaelhárításhoz hasznos segítséget nyújt, a helyi le- 

hetőségek figyelembe vételével. 

Egyszerűen kezelhető MMC beépülő modullal, illetve 

webes konzol segítségével. 

Nyitott API (más gyártók is bővíthetik csomagokkal.) 

Biztonságos (a kliensekkel titkosított csatornán kommu- 

nikál) 

Saját, önálló kliensekkel rendelkezik 

s Automatikus települ 

e Szervízként fut 

HA A kliens képes összegyűjteni a felügyelt számítógépről 
adatokat: 

s Eseménynaplók 


B 
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E Összesített NT-eseménynaplók 


s Támogatott alkalmazások naplóállományai 
s Bármilyen más naplóállomány adatai, amennyiben 
meg tudjuk fogalmazni, hogy milyen módon épül fel. 
TA Ezeket az adatokat már a kliens képes megadott szabá- 
lyok szerint szűrni. 
A A szerveren további szűrések állíthatók be. 


"A A kliens képes az eseményeket konszolidálni, így rövi- 


den, egyszerű formában kerülnek a szerverhez. (pl.: 
egy komplex hiba csak egy eseményként kerül jelentés- 
re a szerver felé.) 
A Képes automatikus beavatkozásra, szabályok alapján 
automatikus cselekvési tervek megvalósítására. (Prog- 
ramfuttatás, szerviz, kiszolgáló újraindítás, stb.) 
Riasztások kiküldésére (SMTP levelek) 
A szerveren a kapott adatok alapján sokféle jelentést 
készíthetünk el rövid idő alatt. (Komplex lekérdezések 
írhatók.) 
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MoM jelentés 


Ezek akár a webes felületen is könnyen megjelenít- 
hetők 











E MoM OpsPortal (webelérés) 


Milyen rendszerkomponenseket támogat? 


Röviden, a teljesség igénye nélkül a támogatott alkalmazások 


listája: 


BEBBEBBBBBBBBBBB 


Active Directory 

Internet Information Server 
Exchange 2000 

SOL 2000 

Terminal services 

DHCP 

DNS 

Systems Management Server 
WINS 

RRAS 

NT eseménynapló 

WAMI események 

SNMP traps 

Syslog 

alkalmazásnaplók 

stb... 


A második részben szó lesz a MoM felépítéséről, bővítőcso- 
magjairól, a tervezés és a bevezetés nehézségeiről, az 
üzemeltetéséről, illetve adok néhány hozzá kapcsolódó ötle- 
tet, tippet, melyek a mindennapi használatát könnyíthetik meg 


Megyesi Barnabás 
Megyesi .Barnabas€meh.hu 
üzemeltetés vezető 





buógyszeresdob Oz 


Windows 2000 Server Resource Kit V. 


Folytassuk tovább kisebb-nagyobb hálózati segédprogramokkal. 


Winschk.exe 


Ez a programocska főleg a WINS adatbázis konzisztencia 
vizsgálatára illetve a WINS szerverek között replikáció el- 
lenőrzésére használható, de ezeken kívül is tud még egy-két 
hasznos dolgot. Természetesen a műveleteket parancssorból 
végezhetjük el és — ahogy az már megszokott a Resource Kit 
programoknál -— akár távolból is. Menüvezérelt, az alábbi 
funkciókból választhatunk: 


Select C:AWINNTAS: 


:SProgran PilessResource Kitdwinzchk 


Io test for names Cin nanez.txt) against WINS servers Cin servers.txt) 
To check version nunber consistencies 

To monitor WINSz and detect conn. failures 

To verify voplícation config zetup 


Io toggyle the interactíve switch (current value: Interactível 
Tg exít this cool. 





B A WinsChk lehetőségei 


Kiemelném az első pontot, amellyel ellenőrizhetjük az összes 
helyi WINS szerver adatbázisát, pl., abból az okból, hogy va- 
jon a (régebbi) kliensek számára döntő fontosságú NetBIOS 
nevek (pl. a DOMAIN[1C]) rekord, amellyel a tartományve- 
zérlőket jelöli a WINS) benne vannak-e ezekben az adatbázi- 
sokban? Az ellenőrzéshez előzetesen két szövegállományt 
kell megetetnünk vele: egy servers.txt nevűt, amelyik a háló- 
zatunkban működő WINS szerver(ek) IP címét tartalmazza, 
valamint names.txt nevűt, amelyben egy-egy sor a keresendő 
neveket és rekordtípusokat tartalmazza csillaggal elválasztva 
és csupa nagybetűvel, pl. így: 






Ha ez van bejegyezve a WinsChk.exe-vel megegyező mappá- 
ban lévő names.txt-ben, akkor a tartomány tartományvezér- 
lőinek illetve főtallózójának bejegyzéséit ellenőrizhetjük majd 
a WinsChk 1. pontja alatt. A csillag utáni bejegyzéseknek 
(azaz a NetBIOS nevek 16. karakterének — NetBIOS suffix) itt 
nézhetünk utána [0163409]. 

A kettes pont alól történhet meg a WINS Server(ek) 
konzisztenciaellenőrzése, a harmadikban pedig a replikáció 
vizsgálata, ami lehet folyamatos (alapbeállítás szerint 3 órán- 
ként egyszer, de ez is állítható ugyanitt), vagy egyszeri is. Az 
eredmény pedig a monitor.log nevű állományban kerül napló- 
zásra. A négyes pontban a replikációs partner(ek) beállításait 
vizsgálja a program. 


WINS Replication Network Monitor Parser 


A Network Monitor a jól képzett rendszergazda ezüstpuskája: 
ha már minden általános hibakeresés és KBIMSDN/Google 
tallózáson túl vagyunk, akkor elő lehet húzni a nyeregkápa 
alól. De sajnos a hálózati problémák nem gyáva indiánok, et- 
től még nem ijednek meg. Így aztán tanuljunk [Inetmoncikk] 


tech.net W:rRttg w i 


[usingnetmon], de segítsünk is magunkon. Használjunk a sze- 
münk előtt pörgő bitsorozatok ismert szekvenciáinak felisme- 
réséhez (a beépítetteken kívül) külső protokoll parsereket, kö- 
rülbelül úgy, mint a plug-in-okat a böngészöknél. Merthogy 
aránylag minimális, de manuális munkával lehetőség van utó- 
lag behegeszteni ezeket a NetMonba. A következő lépések- 
ben a wins.dil azaz a WINS Replication Network Monitor 
Parser kerül beállításra, miután persze bemásoltuk a 
System32WWetmonParsers mappába: 


1. Nyissuk meg a Tcpip.ini-t a System32NetmontParsers 
mappából. 

2. A TCP HandoffSet] részhez adjuk hozzá a "42 - WINS" 
bejegyzést, ahogyan itt is látható: 





3. Mentsük el és zárjuk be a Tcpip.ini-t. 

4. Nyissuk meg a Parser.ini-t a System32WNetmon mappából. 
5. A példához hasonlóan adjuk hozzá "WINS.DLL — 0: WINS" 
bejegyzést a ÍPARSERSI részhez. 





6. A file végére írjuk be a következő sorokat, majd mentsük el 
és zárjuk be. 





Persze ha van hozzá elég lelkierőnk, mi is írhatunk parsert 
Inmparser]. A Resource Kit kettő ilyet tartalmaz, a WINS rep- 
likációs parseren kívül a Windows Load Balancing Serverhez 
is található két .díI a CD-n. Persze a webről is be lehet egyet- 
kettőt szerezni (pl. az NTP-hez [sntpparser]), de sajnos a s0- 
kat emlegetett Kerberos parser továbbra sem hozzáférhető. 
Még egy fontos tudnivalóról szólnom kell: az eredeti Resource 
Kitben lévő wins.dil hibás, a Microsoft később kiadott egy ja- 
vított példányt, amelyet erről a címről [reskitftp)] letölthetünk. 


DNS Provider 


Ezt az összetett csomagot a Resource Kit szabadon letölthető 
részben találjuk meg [reskitftp]. Két fő részből áll: a DNS 
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Windows Management Interface (WMI) Provider 
eszközből, amelyhez tartozó szkriptek VBScript-ben 
íródtak, és egy Perl szkript gyűjteményből. Mindket- 
tő segítségével készíthetünk, szerkeszthetünk és tö- 
rölhetünk DNS zónákat, hostokat, parancsorból és 
távoli gépen is, sőt az WMI változat Excel állományokból is 
képes zónákat, rekordokat, hostokat tehát egy komplett DNS 
alrendszert létrehozni. A letölthető dnsprov.zip ennek megfe- 
lelően tartalmaz egy DNSImport.vbs nevű szkriptet és egy 
Excel mintaállományt is. A telepítés menete a következő: 


1. Másoljuk be a Dnsschema.mof és a Dnsprov.dil állományo- 
kat a vsystem32Nwbem mappába. 

2. Ugyanitt ,hangoljuk rá" az eszközt a DNS szervizre a kö- 
vetkező paranccsal: 


[mofcomp. dnsschema .mof 
3. Ezután már csak regisztrálni kell a Dnsprov.dil-t. 


RegSvr32 dnsprov.d1l 


Ezt a műveletsort minden olyan szerveren meg kell ismétel- 
nünk, amelyen használni akarjuk az eszközt. Az alábbi 
szkripteket használhatjuk ezután: 


Dnsimport.vbs 


Zónák, hostok, rekordok készítése impor- 
tálással az említett módon, Excelből 





Dnsrecord.vbs 
Dnsserver.vbs 
Dnszones.vbs 


Hostok készítése parancssorból 
A DNS szerver paramétereinek beállítása 


Így készítünk pl. egy primary dns zónát parancssorból: 


csceript dnszones.vbs create primary forward 
W altgr.hu 


És lőn egy zónánk, de tegyünk bele egy A rekordot is: 


csceript dnsrecord.vbs /add A altgr.hu srv1 
$ 192.168.1.221 


Ez utóbbi művelet egy másik gépre, egy másik, már létező zó- 
nába: 


csceript dnsrecord.vbs /add A ctrl.hu srv3 
$ 10.0.1.201 /S srv2 /U Administrator /W password 


Ugye milyen egyszerű? A további DNS hekkelés céljából fel- 
hívnám a kedves Olvasó figyelmét a - szintén a csomagban lé- 
vő -  dnsprovider.chm súgóállományra, amelybe elképesztő 
mennyiségű információt, leírást és példát zsúfoltak bele. 


Getmac.exe 


A Getmac.exe a hálózati interfészek MAC címeit valamint 
protokolljainak listáját adja vissza és NetBIOS illetve DNS ne- 
vekkel is használható. Nagyon sok helyen tudjuk használni pl. 





az előbb említett Network Monitornál is, az alapból MAC cí- 
mek barátságosabb elnevezésének apropóján. A Windows 
Server 2003-ban is megtalálható egy alaposan felturbózott 
változata. 


NetSet.exe 


Ezzel az eszközzel a hálózati komponenseket konfigurálhat- 
juk, illetve telepíthetjük vagy leszedhetjük. Például sok azo- 
nos típusú számítógép esetén akár egy válaszfájl segítségével 
felügyelet nélküli telepítést, eltávolítást vagy konfiguráció 
visszaállítást is végezhetünk. A /display kapcsolóval pedig lis- 
tát készíthetünk az aktuális hálózati ügyfelekről, szervizekről 
és protokollokról. 


Wntipcfíg.exe 


Találós kérdés: melyik az a Microsoft operációs rendszer, 
amelyikben parancssori és a grafikus felületen is megtekint- 
hetjük a jelenlegi IP konfigurációnkat? Nem, nem az XP, és 
nem is a Windows Server 2003. Hanem a Windows 98 0 . Bi- 
zony, itt van ipconfig és van winipcfg is. A többin vagy az 
egyik, vagy a másik. De ha akarjuk (vagy éppen megszoktuk), 
ezzel a programocskával a (teljes NT platformon) a GUl-n is 
láthatóvá válnak az IP beállítások. 


Browmon.exe 


Ki ne ismerné a nyolcezressel kezdődő Event Logban szerep- 
lő piros X-es táblákat, amelyek mind a túlságosan demokrati- 
kus (értsd: szavazáson alapuló) módszerrel működő Tallózó 
szolgátatás hibáira utalnak (pl. 8003, a Master Browser ano- 
mália). A Browser Monitor segít a hibák felderítésben, képes 
megmutatni tartományonként pl. a főtallózót, annak egyéb 
funkcióit valamint alapos statisztikát is ad a kezünkbe a grafi- 
kus felületen. 
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implementációja 


A TCP/IP-verem felépítése és főbb funkciói 


A TCP/IP az Internet működésének alapja, és mára a vállalati hálózatokban is a legnépszerűbb háló- 
zati protokollá vált. Útválasztási funkciói maximális rugalmasságot biztosítanak a nagyvállalati háló- 
zatokban is. A TCP/IP-verem megvalósítása és szolgáltatásai tehát döntő fontosságúak minden operá- 


ciós rendszer hálózati funkcióinak felépítésében. 


A TCP/IP és a Windows operációs rendszerek 


A Microsoft a 90-es évek elején indította el azt a projektet, 
amelynek célja egy olyan TCP/IP-verem létrehozása volt, 
amely nagymértékben megnöveli a Windows alapú hálózatok 
skálázhatóságát és teljesítményét. A teljesen újraírt, szabvá- 
nyos TCP/IP-implementáció a Microsoft Windows NT 3.5 
operációs rendszerben mutatkozott be, és ezután minden 
egyes NT alapú Windows verzió megjelenésével továbbfejlő- 
dött, új képességeket, szolgáltatásokat vonultatott fel, és a tel- 
jesítmény növekedésével párhuzamosan egyre biztonságosab- 
bá és megbízhatóbbá vált. 


A TCP/IP-stack folyamatos fejlesztésének céljai szerint az imp- 
lementáció: 
HA szabványos és minél szélesebb körű együttműködésre 
képes 
hordozható 
jól skálázható 
gyors 
rugalmas 
önbeállításra képes és könnyen felügyelhető. 


BEBBBB 


A Windows Server 2003 TCP/IP-implementációja lehetővé te- 
szi, hogy a Microsoft rendszereket nagyméretű vállalati, kor- 
mányzati, vagy nyilvános hálózatokba integráljuk, és megte- 
remti az így felépített rendszerek biztonságos üzemeltetésé- 
nek feltételeit. 

A Windows Server 2003 telepítésekor a TCP/IP-protokoll is te- 
lepítésre kerül, és a korábbi verziókkal ellentétben eltávolítá- 
sa sem lehetséges. 


A Windows 2003 TCP/IP-architektúrája 


A Windows TCP/IP központi elemekből (például ARP, IP, TCP 
protokollok, stb.), szolgáltatásokból (DHCP, DNS, stb.) és a 
köztük lévő csatolófelületekből áll. A csatolófelületek közül a 
TDI (Transport Driver Interface) és az NDIS (Network Driver 
Interface Specification) nyilvánosan hozzáférhetők, az 
[whdcddk] címen elérhető Microsoft Windows Driver 
Development Kit-ek (DDK) tartalmazzák specifikációt és a 
programozási információkat. 
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Alkalmazások és user módban futó szolgáltatások 
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2 A Windows 2003 TCP/IP szerkezeti modellje 
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.] — Az NDIS-csatolófelület és az adatkapcsolati réteg 
(data link layer) funkciói 





A Microsoft hálózati protokolljai a Network Device 
Driver Specification (NDIS) segítségével kommuni- 
kálnak a hálózati csatolók drivereivel. Az OSI- 
modell adatkapcsolati rétegének jelentős részét is a protokoll 
stack valósítja meg, hogy a hálózati csatolók drivereinek fej- 
lesztése egyszerűbb lehessen. A Windows 2003 az NDIS 5.1- 
es verzióját tartalmazza, amelynek új funkciói a következők: 

MA Értesítés Plug ánd Play és az energiagazdálkodással 
kapcsolatos eseményekről (Plug and Play and Power 
Event Notification) — Lehetővé teszi, hogy a hálózati 
csatolók miniport driverei értesítést kapjanak új esz- 
köz csatlakoztatásáról és eltávolításáról, vagy például 
a készenléti üzemmódból való visszatérésről. 

A Küldés leállításának támogatása (Send Cancellation) — 
A hálózati protokolloknak nem kell hosszú ideig vár- 
niuk a küldési kérelmek teljesítésére. 

A Megnövelt statisztikai számlálók (64 bit) — Ez a válto- 
zás lehetővé teszi a korrekt hálózati statisztikák meg- 
jelenítését még nagy sebességű hálózati csatolások 
esetén is. 

A Teljesítménnyel kapcsolatos fejlesztések — Számos 
változás történt annak érdekében, hogy a kritikus há- 
lózati utak gyorsabbak lehessenek, és ne készüljenek 
fölösleges másolatok a hálózati csomagokról. 

H Változás a Wake on LAN szolgáltatásban — Beállíthat- 

juk, hogy csak a magic packet-ek váltsanak ki ébresz- 
tést. 


A Windows 2003 része továbbá a távoli NDIS (Remote NDIS), 
amely külső szoftver telepítése nélkül lehetővé teszi az USB 
csatlakozású hálózati eszközök használatát. 
Az adatkapcsolati réteg funkcióit a hálózati csatoló hardver a 
hozzá tartozó driver szoftver és a TCP/IP-stack alacsony szin- 
tű része valósítja meg. A hálózati csatoló által hardveresen 
megvalósított szűrők a csomagokban lévő MAC (media access 
control) alapján válogatják ki az adott gépnek érkezett csoma- 
gokat. A kártya a beérkező csomagok cél (destination) címme- 
zőjét figyeli, és minden csomagot eldob, amelyben a mező ér- 
téke nem felel meg az alábbi feltételek valamelyikének (vagy 
hibás CRC-vel érkezik): 
IA A mező a csatoló saját címét tartalmazza 
HA A mező broadcast címet tartalmaz (OXFF-FF-FF-FF-FF- 
FF) 
Mm A mező olyan multicast címet tartalmaz, amelynek fi- 
gyelésére a protokoll driver utasítást kapott az 
NDISReguest() függvény használatával. 


A legtöbb hálózati csatoló esetében azonban ez a szűrés ki- 
kapcsolható, ebben az esetben minden csomag (amelynek 
CRC-je megfelelő) továbbkerül a meghajtóprogramhoz. 
Mivel a szűrés hardveresen történik, a csomagok válogatása 
egyáltalán nem igényel CPU-időt. A szűrőn átjutott csomago- 
kat ezután a hálózati csatoló meghajtóprogramja kapja meg 
hardver megszakítás segítségével. Mivel a meghajtóprogram 
az adott számítógépen futó szoftver, az idáig eljutó csomagok 
feldolgozása már CPU-időt is igényel. Ezután a meghajtóprog- 
ram a rendszermemóriába másolja a csomagot, és értesíti a 
csatolt szállítási meghajtókat. 

Miközben a csomag a hálózaton vagy hálózatokon halad át, a 
benne lévő forrás (source) MAC-cím mindig annak a hálózati 


csatolónak a címe, amely a csomagot a médiára helyezte, a 
célcím (destination address) pedig azé, amelynek majd a cso- 
magot le kell vennie a médiáról. 

Ez azt jelenti tehát, hogy ha a csomag útválasztókon (router 
vagy hálózati rétegben működő, Layer 3 switch) halad át, a 
forrás és célcímek minden egyes ilyen eszközön áthaladva 
változni fognak. 

Az adatkapcsolati réteg feladatai közé tartozik még az adott 
médiához tartozó Maximum Transmission Unit (legnagyobb 
átvihető adategység, MTU) meghatározása és az érték továb- 
bítása a feljebb lévő protokollok felé. A csatolóhoz tartozó 
MTU-t felhasználja például a TCP-protokoll is az adott média 
optimális csomagméreteinek meghatározásához. 


A központi komponensek és a TDI csatolófelület 


A TCP/IP központi komponenseit a Windows Server 2003 
tepip.sys drivere valósítja meg. A komponensek a hálózati 
csatoló felől az NDIS, az alkalmazások felől pedig a TDI csa- 
tolófelületen keresztül érhetők el. A legfontosabb központi 
komponensek a következők: 

Address Resolution Protocol (ARP) 

Internet Protocol (IP) 

Internet Control Message Protocol (ICMP) 

Internet Protocol Security (IPSec) 

Internet Group Management Protocol (IGMP) 
Transmission Control Protocol (TCP) 

User Datagram Protocol (UDP) 
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Az Address Resolution Protocol (címfeloldási protokoll) végzi 
a kimenő csomagok MAC-címének meghatározását az IP- 
címek alapján. Minden kifelé tartó IP-datagramhoz hozzá kell 
csatolni a forrás és a cél MAC-címeit. A cél MAC-címének 
meghatározásához az ARP broadcast kérést küld ki az alháló- 
zatra. Az ARP-kérelem megválaszolásakor mind a válasz kül- 
dője, mind az eredeti kérelmező feljegyzi a másik IP és MAC 
címét egy helyi táblázatba, melynek neve ARP-gyorsítótár 
(cache). 


H ARP gyorsítótár 


ellenőrzése 


ARP-bejegyzés 
hozzáadása 
EH "pr-kérés küldése 
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BH ARP-bejegyzés hozzáadása 


E Az Address Resolution Protocol működése 


A gyorsítótárat az ARP a broadcast üzenetek számának csök- 
kentésének érdekében tartja fenn. Ebben megtalálhatók az IP- 
címekhez tartozó MAC-címek. Az ARP-gyorsítótár mind stati- 
kus, mind dinamikus bejegyzéseket tartalmazhat. A dinamikus 
bejegyzések az idő előrehaladtával automatikusan kerülnek 
hozzáadásra és eltávolításra, a statikus bejegyzések viszont a 
számítógép újraindításáig a gyorsítótárban maradnak. 

Az ARP-gyorsítótár dinamikus bejegyzéseinek várható élettar- 
tama 10 perc. A gyorsítótárhoz hozzáadott minden új bejegy- 
zés időbélyeget kap, és ha a hozzáadástól számított 2 percen 





belül nincsen rá újra szükség, érvényessége lejár, kikerül az 
ARP-gyorsítótárból. Az újra használt bejegyzések élete min- 
den alkalommal két perccel meghosszabbodik, de 10 perc 
után mindenképpen törlődnek a gyorsítótárból. Az ARP- 
gyorsítótár tartalmát az 
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paranccsal jeleníthetjük meg. 

Az ARP arra is felhasználható, hogy helyi útválasztóknak to- 
vábbítson IP-datagramokat, ha a csomag célállomása, nem az 
adott alhálózaton van. Ilyen esetben az ARP a helyi hálózaton 
működő útválasztó MAC-címét keresi meg. 


Az Internet Protocol (IP) feladata a csomagok (ezen a szinten 
a csomagok hivatalos neve datagram) címzése és továbbítása. 
Minden IP adatcsomag tartalmazza a forrás és a cél IP-címét. 
A MAC-címektől eltérően a csomagban lévő IP-címek a 
datagram teljes élete alatt állandóak maradnak. Az IP-réteg 
alapfunkciói a következők: 

A Útválasztás - Az IP- réteg elsődleges funkciója az útvá- 
lasztás. Az adatcsomagok az UDP, TCP, stb. protokol- 
loktól, illetve a hálózati csatolóktól érkeznek az IP-hez. 
Az IP-fejlécet (cél IP-cím) megvizsgálva és az útvonal- 
táblával (routing table) összehasonlítva az IP eldönti, 
hogy az adott csomagot a felső rétegek vagy a hálózati 
csatoló felé kell továbbítania, esetleg egyszerűen el- 
dobhatja azt. A Windows Server 2003 TCP/IP új lehe- 
tősége az Automatikus metrika opció megadása a há- 
lózati csatoló tulajdonságlapján. A metrika az IP útvá- 
lasztási táblázatban az adott útvonal költségét jelző 
szám. Lehetővé teszi a legjobb útvonal kiválasztását az 
adott célhoz vezető lehetséges útvonalak közül. Ha az 
opciót engedélyezzük, a TCP/IP automatikusan hatá- 
rozza meg az útválasztási táblázatban lévő útvonalak 
mertrikáját az IP-cím, az alhálózati maszk és a helyi há- 
lózati kapcsolatok alapértelmezett átjárója alapján. A 
kapcsolat metrikájának automatikus meghatározása, 
amely alapértelmezés szerint engedélyezve van, meg- 
határozza minden egyes kapcsolat sebességét, és min- 
den egyes kapcsolat útvonalának metrikáját úgy állítja 
be, hogy a leggyorsabb kapcsolat a legalacsonyabb 
metrikával hozza létre az útvonalakat. 

H IP cím ütközés érzékelése — a duplikált IP-címek kere- 
sése a TCP/IP stack inicializálásakor, illetve új IP-cím 
beállításakor történik. Ekkor a gép broadcast ARP- 
üzenetek formájában kiküldi a beállított IP-címet a há- 
lózatra. A kiküldött ARP kérések száma alapértelmezés 
szerint három, de a szám a 
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registry érték létrehozásával beállítható. 

Ha egy másik számítógép válaszol az ARP-kérések va- 
lamelyikére, az IP-cím már használatban van a hálóza- 
ton. Statikus IP-cím esetén az esetben a gép az adott 
hálózati csatoló letiltásával indul, hibaüzenet kerül a 
rendszernaplóba, és jelenik meg a képernyőn. Ha az 
IP-cím DHCP-kiszolgálótól származik, a gép nem tiltja 
le a csatolót, hanem DHCPDecline üzenetben értesíti a 
kiszolgálót a címütközésről, és új címet kér. 





Internet Control Message Protocol (ICMP) — Az 
ICMP segítségével az IP-kommunikációt használó 
állomások és útválasztók hibákat jelezhetnek, és 
korlátozott adatcserét folytathatnak a vezérlésről és 
állapotokról. 
Az ICMP-üzeneteket a Windows 2003 Server a következő 
feladatokra használja: 
A Az útválasztó vagy célállomás kézbesítési problémái- 
nak jelzése. 
Az útválasztó táblák felépítése és karbantartása. 
Útválasztó felderítés (Router Discovery) 
A Path Maximum Transmission Unit (útvonal legna- 
gyobb átviteli egysége, PMTU) meghatározásában va- 
ló közreműködés. 
AA Elérhetőségi problémák felderítése (ping, tracert, 
pathping). 
A Az IP-útválasztó (router) ICMP-üzenet formájában jel- 
zi túlterheltségét a küldő állomásoknak. 
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[E IP datagram ————— 


IP-tartalom 
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2 IP datagramba ágyazott ICMP-üzenet 
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Internet Protocol Security (IPSec) — Az IPSec titkosításra épülő 
védelmi szolgáltatások és biztonsági protokollok együttese, biz- 
tosítja az adatintegritást, az adatok eredetének hitelesítését, az 
adatok titkosságát, és az adatáramlás titkosítását. Használata 
nem igényli az alkalmazások, illetve a protokollok módosítását, 
így az IPSec könnyen telepíthető meglévő hálózatokon is. 

Az IPSec az alábbiakban felsorolt biztonsági szolgáltatásokat 
kínálja, illetve használja. 

Biztonsági tulajdonságok 

Nyilvános kulcsú tanúsítványon alapuló hitelesítés 
Előmegosztott kulcson alapuló hitelesítés 

Nyilvános kulcsú kriptográfia 

Az adatok sértetlenségének védelme kivonatoló függ- 
vényekkel 

Az adatok védelme titkosítással 

Kulcskezelés 
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Internet Group Management Protocol (IGMP) — Az IGMP 
olyan protokoll, amelynek segítségével az IP-állomások közlik 
a velük szomszédos csoportos küldést (multicast) alkalmazó 
útválasztókkal, hogy mely csoportos küldési csoportok tagjai. 
Az IP csoportos küldés (multicast) célállomások csoportjának 
történő adatcsomag küldést jelent. A multicast adatcsomag a 
célcsoport minden címére megérkezik, a unicast IP csomag- 
küldéshez hasonló megbízhatósági szinttel, vagyis a datagram 
hibátlan megérkezése és a helyes sorrend nem garantált a cso- 
port minden tagja számára. 

A csoportok tagsága dinamikusan változik — az állomások bár- 
mikor csatlakozhatnak, vagy távozhatnak a csoportokból. A 
csoporttagok fizikai helyére vagy számára vonatkozóan sem- 
milyen korlátozás nincs, és egy állomás több csoport tagja is 
lehet egyszerre. 


E 


ka 


- PIDIJRINaMatTd ut -g[/d11 £002 SMOPRULM BH / 


IOPJYUNy gg0j sa asajtdataj maran.girdil d 


15 





- KÖ TCP/IP-verem felépítése és föbb funkciói, [Ddnd 0 1 5 


AR Windows 2003 TCP/IP-implementációja 


16 


Transmission Control Protocol (TCP) - A TCP 
összekötettés alapú, megbízható kapcsolatot biztosít 
az alkalmazások számára. A Microsoft rendszerek 
hálózatkezelése a TCP-protokollt használja a beje- 
lentkezéshez, a fájlok és nyomtatók megosztásához, 
a tartományvezérlők közötti replikációhoz, a tallózó (browse) 
információk cseréjéhez, és más funkciókhoz. A Windows 
2003 által támogatott főbb TCP-funkciók a következők: 

TCP vételi ablak méretének meghatározása és beállítása. 
Késleltetett visszaigazolás 

Szelektív visszaigazolás 

TCP időbélyegek 

Útvonalhoz tartozó legnagyobb átviteli egység (Path 
Maximum Transmission Unit, PMTU) meghatározása. 
Nem működő átjáró felismerése (Dead Gateway 
detection) 

A TCP csomag újraküldési módok 
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A TCP-protokoll tervezésekor fontos szempont volt, hogy a 
legkülönbözőbb kapcsolati feltételek esetében is képes legyen 
az optimális átviteli teljesítményt biztosítani. Az adott kap- 
csolaton elérhető sávszélesség legfontosabb tényezői a követ- 
kezők: 

mM A kapcsolat sebessége (másodpercenként átvihető bi- 
tek száma) 
Továbbítási késleltetés 
Átviteli ablak mérete 
A kapcsolat megbízhatósága 
A hálózat és az átviteli eszközök terhelése 
Útvonalhoz tartozó legnagyobb átviteli egység 
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User Datagram Protocol (UDP) - Az UDP olyan, kapcsolat 
nélküli datagram-szolgáltatást biztosító TCP-kiegészítés, 
amely sem a kézbesítést, sem a csomagok megfelelő sorrend- 
jét nem garantálja. A Microsoft hálózati komponensei beje- 
lentkezéshez, tallózáshoz, és névfeloldáshoz használják az 
UDP-protokollt. 


Transport Driver Interface (TDI) — A TDI olyan általános ru- 
tincsoport, amely lehetővé teszi, hogy a különböző hálózati 
rétegekben lévő összetevők kommunikáljanak az OSI-modell 
munkameneti rétegével. Ezen rutinok segítségével az átviteli 
réteg alatt és fölött elhelyezkedő programösszetevők a prog- 
ram módosítása nélkül működhetnek együtt. 

A Microsoft azért fejlesztette ki a TDI-t, hogy a régebbi csato- 
lófelületeknél (NetBIOS, Windows Sockets) nagyobb rugal- 
masságot, és bővebb funkcionalitást biztosítson. A TDI- 
specifikáció alapvető funkciókat ír le, amelyek segítségével a 
meghajtóprogramok és a TDI-ügyfelek kommunikálhatnak 
egymással. 


A Windows 2003 Server redirector és server szolgáltatása köz- 
vetlenül A TDI-csatolófelületet használja a NetBIOS helyett, 
mivel így megkerülhető a NetBIOS számos korlátozása. 


Hálózati alkalmazások csatolófelületei 


A hálózati alkalmazások számos felületen keresztül kommuni- 
kálhatnak a TCP/IP központi komponenseivel: 
A A redirector szolgáltatáson keresztül (például named 
pipes) 
A A NetBIOS csatolófelület segítségével (NetBIOS over 
TCPAP) 
A A Windows Sockets csatolófelület segítségével 


A legfontosabb ügyfélszolgáltatások 


Az egyik legfontosabb ügyfélszolgáltatás a Dynamic Host 
Configuration Protocol (DHCP). A DHCP a helyi hálózaton 
lévő DHCP-kiszolgáló IP-címekből álló adatbázisából teszi 
lehetővé az IP-címek dinamikus hozzárendelését az ügyfe- 
lekhez. 

A Windows 2000 rendszerrel működő számítógépek alapér- 
telmezés szerint először megpróbálnak a hálózaton kapcsola- 
tot létesíteni egy DHCP-kiszolgálóval, hogy dinamikus beállí- 
tási adatokat kapjanak a telepített hálózati kapcsolatokról. 
Ha a DHCP-kiszolgálót sikerült elérni, és a kiosztott beállítá- 
sok működnek, akkor a TCP/IP beállítása sikeresen befeje- 
ződik. 

Ha nem sikerült elérni a DHCP-kiszolgálót, akkor a számító- 
gép az APIPA (Automatic Private IP Addressing) szolgáltatással 
automatikusan beállítja a TCP/IP protokollt. Ha az APIPA szol- 
gáltatást használja, a Windows 2003 a 169.254.0.1 és 
169.254.255.254 értékek közötti fenntartott IP-címtartomány- 
ból jelöl ki címet. Ez az IP-cím a DHCP-kiszolgáló helyének 
meghatározásáig átmeneti beállításként fog működni. Az alhá- 
lózati maszk a 255.255.0.0 értéket kapja. 

A Windows Server 2003 támogatja a DNS adatok dinamikus 
frissítését, a DHCP-kiszolgáló által kiosztott IP-címek is auto- 
matikusan bekerülnek a DNS-kiszolgáló adatbázisába. 


Összegzés 

A Windows 2003 TCP/IP implementációja számos szabvá- 
nyos funkció támogatását tartalmazza, a korábbiakhoz képest 
számos teljesítmény-optimalizáló változást, és új szolgáltatást 
tartalmaz. A Windows Server 2003 így kiválóan beilleszthető, 
és biztonságosan üzemeltethető komplex, nagyméretű háló- 
zati környezetekben is, 
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A címkiosztó szolgáltatás üzembehelyezésekor különösen fontos jól megválasztani a 


helyszínt. Egyszerű környezetben, ha nincs is több telephely, ez nem probléma, ma 
azonban már egyre több összetett hálózat működik. Lehet a topológia bármilyen bo- 
nyolult, a DHCP szervereknek megfelelően kell működniük. 


Az egyszerű nagyszerű? 


Tudjuk már, hogy a DHCP-rendszerek a szórt üzenetekre épí- 
tenek. Nincs is más lehetőségük, hiszen a minden információ- 
áramlás alapját jelentő egyedi IP-cím kiosztása a feladatuk. 
Egy ,kommunikációképtelen" ügyféllel kommunikálnak, s vé- 
gül alkalmassá teszik őket az adatcserére. 

A szórt üzenetek azonban a helyi hálózat foglyai, az útválasz- 
tók nem engedik át a broadcast csomagokat — ezáltal csök- 
kentve a WAN vonalak és a többi LAN terhelését. 

A fenti két állításból az következik, hogy minden DHCP- 
kiszolgáló a saját LAN-jának csapdájában kellene vergődnie, 
s bár helyben nagyszerű, távoli hatása nincs. A huszáros 
megoldás, amely a hálózat aktív tagjaivá teszi az állomásokat, 
csődöt mond, ha ki kellene terjeszteni. Hacsak nincs a tarsoly- 
ban egy újabb trükk. Nos, van ilyen. 


A DHCP továbbító ügynökök (Relay Agent) 


A Windows NT4, Windows 2000 és Windows 2003 rendsze- 
reknek van egy speciális, a DHCP-szervereket támogató szol- 
gáltatása, ezek a továbbító ügynökök. Az NT4-ben még külön 
szolgáltatásként telepíthető (gyakran összekeverték a DHCP 
kiszolgálóval és telepítették is), a Windows 2000-ben az RRAS 
szolgáltatás része. 
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fopens property sheet for the current selection. 


8 A továbbító ügynök az RRAS szolgáltatás egyik funkci- 
ója 


Egy továbbító ügynök feladata borzasztóan egyszerű: elkapja 
a helyi hálózatban kószáló DHCP-kiszolgálóknak szánt cso- 
magokat, majd azokat a beállításai szerint egy vagy több — 
más alhálózaton működő - DHCP szerver felé továbbítja. 
Egyből érthető a trükk: a szórt üzenetek az ügynök , kezei 
közt" egyszerű unicast csomagokká válnak, így könnyedén, 
akár több útválasztón is áthaladhatnak. Mindezt azért tudja 
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megtenni a Relay Agent, mert a DHCP szabvány, egészen 
pontosan az RFC 1542, a DHCP csomagban definiál egy 
,Relay IP Address" mezőt (Ezt ismerik úgy is, mint , Gateway 
IP Address, vagy GIADDR). Az ügynök ide írja bele a saját cí- 
mét, ettől egy csapásra minden DHCP kiszolgáló unicast cso- 
magokkal kezd el kommunikálni vele. A DHCP szerver az 
ügynök kérését kiértékeli, méghozzá az IP-címe alapján. Azt 
vizsgálja, hogy az IP-címhez, amelyről a kérés érkezett, tarto- 
zik-e egy scope. Ha például az ügynök címe 10.1.0.10/16, 
van-e olyan bérlettartomány a szerveren, amelynek akár ez a 
cím is tagja lehetne. Ha igen, a szolgáltatás kiad egy bérletet. 
A megérkező válaszokat úgy küldi tovább a Relay Agent az 
ügyfeleknek, mintha csak egy valódi címkezelő lenne. 

Az egyszerű működéséhez egyszerű konfigurálás tartozik. A 
beállítás csupán négy paramétert érint. Meg kell adnunk azt 
az interfészt (hálózati kártyát), amelyre a szolgáltatás működ- 
ni kezd, és fel kell sorolnunk azokat a DHCP-kiszolgálókat, 
amelyeket az ügynök értesít, ha helyi címkérelmet fog el. 


E 
Eg Dynarnic Host Configuration Protocol (DHCP) Interface 








Hop-count threshold: 4 z 
Boot threshold (seconds): 4 És 


a Az ügynökkonfigurálás nem ördöngösség 


Ezen felül meg lehet változtatnunk az un. Hop-count 
threshold értéket. A paraméternek igazi jelentősége nincs. Tu- 
lajdonképpen az IP csomag TTL értékéhez hasonló mezőről 
van szó, de attól külön kezelik. Azt jelenti, hogy maximum 
ennyi Relay Agenten keresztül jöhet a csomag. Azért nincs a 
gyakorlatban jelentősége, mert bár a szabvány szerint egy 
ügynök az elkapott címet broadcast, multicast vagy unicast 
címre továbbíthatja, és így elméletileg elképzelhető, hogy 
több Agentnél is megfordul a DHCP-Discover csomag, gya- 
korlatilag kizárólag unicast címeket használnak az ügynökök, 
közvetlenül a kiszolgálókat megcímezve, tehát szinte soha- 
sem kap ez a mező 1-nél magasabb értéket. 

A Boot threshold paraméter már hasznosabb. Ennek segítségé- 
vel két külön hálózatban lévő DHCP kiszolgálót (egyéb konfi- 
gurációs trükkök mellett) egymás tartalékává tehetjük még- 
hozzá úgy, hogy a helyi kiszolgáló lesz a preferált. A boot 
thresholdban meghatározott másodpercig vár ugyanis az ügy- 
nök, mielőtt továbbítaná az üzenetet a (távoli) kiszolgálónak. 
Amennyiben van helyi DHCP szerverünk, és az ügynököt 
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csak arra használjuk, hogy a távoli kiszolgálót, mint 
tartalékot elérje, a négy másodperc bőven elegendő 


I 
/ ] a helyi címkiosztónak az IP-cím allokálásához, tehát 


a kívánatos rendszert használták az ügyfelek. 

Amennyiben a helyi DHCP-kiszolgáló nem műkö- 
dik, az ügynök elvégzi a rábízott munkát és továbbítja a tarta- 
lék rendszer felé a kérelmeket. A DHCP rendelkezésre állásá- 
nak növelését szolgáló technikák ismertetésekor erre a felépí- 
tésre még visszatérünk. 


A hálózat-topológia és a DHCP 

Most, hogy az ügynökökkel a címkiosztó szolgáltatás olyan, 
akár a ,börtönéből szabadult sas", nézzük sorra a kiszolgálók 
elhelyezésének alapeseteit. Szeretném előrebocsátani, hogy 
az alábbiaknál sokkal bonyolultabb elrendezések is léteznek, 
amelyeket később majd tárgyalunk is, most csak a leglényege- 
sebbeket tekintjük át. 

A teljesen egyértelmű környezet, amikor nincs is útválasztónk, 
csupán egy LAN-unk, rajta ügyfelek és egyetlen DHCP- 
szerver. Elegendő egyetlen scope, habár korábban láthattuk, 
hogy nem lehetetlen több cím-intervallum használata sem. 







Scopet: 
172.16.0.1-172.16.0.254 


DHCPIszerver 


DHCP kliens 


DHCP kliens DHCP kliens 


a A kályha: egy DHCP kiszolgáló, egy alhálózat 


Az előző esetnél egy icipicit bonyolultabb, amikor több LAN- 
t egy útválasztó köt össze. Ekkor a távolabbi helyi hálózat ügy- 
felei csak akkor kaphatnak IP-címet, ha a router maga futtat 
egy DHCP továbbító ügynöki funkciót. Ma már az útválasztók 
többsége képes erre — csupán annyit kell tennünk, hogy a 
megfelelő beállításokat elvégezzük. 


Scope1 
172.16.0.1-172.16.0.254 
Scope2: 


172.16.1.1-172.16.0.254 él hb Le 
Sz ú 


Router DHCP 
Relay Agert-el 












DHCP kliens . DHCP kliens . DHCP kliens 
DHCP kliens. DHCP kliens . DHCP kliens 


c Egy címkiosztó szerver több alhálózattal 


A fenti ábrán látható konfiguráció azonban sok esetben csak 
illúzió. Először is ritka eset, amikor egy helyi hálózatot egyet- 
len router választ el egy másiktól. Egyetemi hálózatokon, egy- 
egy nagyobb város hálózatában elképzelhető, ezzel együtt 
nem jellemző. Másrészt a topológia azt feltételezi, hogy az út- 
választó konfigurálása a kisujjunkban van. 


Kis magyar valóságunk nem ilyen. Ha vannak routerek, azt 
többnyire a külső szállító felügyeli (sokszor ő is birtokolja). Ha 
a címkiosztást ilyen körülmények között a magunk kezében 
akarjuk tudni, úgy szükségünk lesz egy saját továbbító ügy- 
nökre. 

Ekkor már mindegy, hogy hány eszköz választja el egymástól 
a helyi hálózatokat, s hogy azok milyen messze vannak egy- 
mástól. A következő ábra modellezi azt a szituációt, amely- 
ben a leginkább elkél a továbbító ügynök. Könnyű elképzelni, 
hogy a bal oldali hálózatához, a központhoz, több olyan LAN 
kapcsolódik, mint a jobb oldalon látható, vagyis egyetlen 
DHCP szolgáltatást akár több tucat telephelyet is elláthat. To- 
vábbító ügynökök kérdése az egész. 


Scopet 
172.16.0.1-172.16.0.254 









Scope2: 
172.16.1.1-172.16.1.254 





DHCP Relay Agent 





DHCP kliens. DHCP kliens . DHCP kliens 


DHCP kliens. DHCP kliens . DHCP kliens 


G Ha nem mi felügyeljük az útválasztókat 


A skálázhatóságról csak annyit, hogy a Microsoft ajánlása sze- 
rint ne rakjunk egy DHCP-kiszolgálóra 1000-nél (!) több bér- 
lettartományt. Összesen pedig ne legyen több, mint 10000 
ügyfele egy szervernek. Ha valaki takarékoskodni szeretne a 
címkiosztó szerverekkel, akár a legnagyobb kiterjedésű ma- 
gyar LAN is néhány szerverrel elüzemel. Ugye, hogy 
börtönéből szabadult a DHCP? 

A továbbító ügynöknek még egy nagyon fontos szerep jut, 
ugyanis a betárcsázáskor is hárul reá feladat. Ezt a szituációt 
ábrázolja a következő kép. 






7 RAS kliens 





Scopet 
172.16.0.1-172.16.0.254 
Scope2: 
172.16.1.1-172.16.1.254 


















RRAS szerver 







DHCPÍIszerver 


DHCP kliens 


DHCP kliens DHCP kliens 


EG Betárcsázás és DHCP 


Ahhoz, hogy megértsük, milyen szerepe van a Relay Agent- 
nek, meg kell vizsgálnunk az RRAS és a DHCP viszonyát. Lát- 
ni fogjuk, hogy nemcsak a továbbító ügynök tetszeleg néha a 
DHCP tulajdonságaival, hanem az RRAS is. 

A Routing And Remote Access — ahogyan a nevében is mutat- 
ja, többek között útválasztással és betárcsázással kapcsolatos 
szolgáltatásokat nyújt. Amikor egy távoli, telefonos kapcsolat- 
tal rendelkező ügyfél betárcsáz, tulajdonképpen egy útválasz- 


tó kel életre, amelynek egyik lába egy hálózati kártya, a má- 
sik pedig egy modem. A DHCP úgy kerül a képbe, hogy az 
RRAS-nak valamilyen módon gondoskodnia kell a távoli szá- 
mítógép modemes lábának IP-címmel való ellátásáról. 
Többféle lehetőség is létezik. Elvileg beállítható kézzel egy IP- 
cím a kliensnél, még egy modemes kapcsolathoz is. Na de a 
dinamikus címek korában? És ha egy másik hálózathoz szeret- 
nék csatlakozni? Vagy egy nagy hálózat másik alhálózatán ke- 
resztül lépek be? A statikus cím nem igazán járható. 

Egy másik megoldás lehet(ne), ha a felhasználó kap egy IP- 
címet. Ezt megadhatjuk az ADUC felületén keresztül, de az 
eredmény hasonló lenne az előzőekhez. Kénytelenek leszünk 
az RRAS-ra bízni a cím átadását. Ekkor kezd egy router DHCP 
tollakkal ékeskedni. 

Az RRAS kiszolgáló tulajdonságai párbeszédpanelen egy kü- 
lön fül foglalkozik az IP-címek kezelésével. Íme, az alábbi 
képre gondolok. 













ka Eg 


AJKSERYER3 (local) Properties 


General] Security IP lFPP ] Event Logging ] 


[7 Enable IP routing 
[7 állow IP-based remote access and demand-dial connections 
IP address assignment 
This server can assign IP addresses by using: 
6 Dynamic Host Configuration Protocol (DHCP) 
C Static address pool 





. ] Number] IP Add... ] Mask! 





b£dd Edit. I 


Use the following adapter to obtain DHCP, DNS, and WINS addresses for 
dial-up clients. 


Adapter 








Cancel I Apply 


E Az RRAS-t és a DHCP-t ezen a panelon , lőhetjük 
össze" 





A cím kiosztására két lehetőség is adott. A legegyszerűbb, ha 
mindent az alapértelmezett értéken hagyunk. Ekkor az RRAS 
címeket kér (előre) a DHCP kiszolgálótól, méghozzá 10 dara- 
bot. Egyet lefoglal magának, a többit pedig szükség szerint 
kiosztja a betárcsázó ügyfeleknek. Ha mind a tíz cím elfogy- 
na, akkor kér újabb tizet és így tovább. Az alábbi címen 
egyébként a kikért címek száma módosítható: 






tcontrolsett 
esstParame: ersWIpN v 
ki CA LATSS ze SzőSTSTz 





A címkérés az RRAS indulásakor történik. Amennyiben ekkor 
nem érhető el DHCP szolgáltatás, az RRAS az APIPA által 
meghatározott címek közül oszt ki majd az ügyfeleknek. Ha 
valaki 169.254.x.x címeket lát, és azt panaszolja, hogy nem 
tudja elérni a belső hálózatot, az gyanakodjon a DHCP és az 
RRAS közötti kommunikációs zavarra, és legalább egyszer in- 
dítsa újra a betárcsázó szolgáltatást úgy, hogy meggyőződött a 
DHCP helyes működéséről. 





A fenti ábrán az is látható, hogy meghatározhatjuk ET 


azt az adaptert, ahonnan a RAS a különböző opció- f-i 
kat veszi. Ez kérem itt egy csapda. Az igaz, hogy az 

RRAS címeket kér a címkiszolgálótól. Egyéb opció- 

kat azonban nem kér! A most emlegetett sor tehát 

azt mutatja meg, hogy az RRAS melyik hálózati kártyájának 
beállítását veszik át majd a betárcsázó ügyfelek. Az első és 
legfontosabb dolog tehát a RRAS LAN kártyájának nagyon 
korrekt beállítása. Egy rövid táblázat arról, milyen IP konfigu- 
rációs értéket honnan vesz az RRAS 





ag ti 
IP address DHCP kiszolgálótól az RRAS-on 
keresztül 
WINS server . RRAS LAN adapter beállítása es 
DNS server . ] RRASLAN adapter beállítása 


Subnet mask Az IP-cím alapján, automatikusan 
Class A,B vagy C subnetet kap 

az ügyfél 

. Nem továbbítódik EE 

Ha az RRAS-nak nincs WINS szervere, 
akkor a kliens b-node lesz, egyébként 
h-node a kapcsolat ideje alatt. 


NetBIOS scope ID [/ 
Node type 





No és a korábban emlegetett DHCP RRAS opciókat sem küldi 
át az RRAS? Nem, azokkal sem foglalkozik. Viszont az ügyfe- 
lek a kapcsolat létrejötte után küldhetnek egy DHCPINFORM 
csomagot, amelyben a megfelelő opciókat kérik. Itt jön a to- 
vábbító ügynök újabb feladata. Amennyiben az IP-címeket 
DHCP kiszolgálótól kapta az RRAS is, az ügynök automatiku- 
san továbbítja az ügyfelek csomagjait ennek a címkiosztónak. 
Ha viszont statikus címlistával dolgoztunk az RRAS-on, akkor 
csak abban az esetben működik a továbbítás, ha az ügynököt 
külön konfiguráltuk, vagyis megmondtuk, hogy mely 
címkiosztó rendszerrel vegye fel a kapcsolatot. 

A betárcsázó ügyfelek persze mit sem tudnak arról, hogy a cí- 
meket nem közvetlenül egy címkiosztó szervertől kapták. Szá- 
mukra csak az a lényeges, hogy megkapják a hőn áhított IP- 
címet, hozzá a megfelelő paramétereket és végre kommuni- 
kálhassanak. Nekünk rendszergazdáknak azonban nem árt 
tisztában lennünk, hogy ez a többnyire problémamentes 
összekapcsolódás valójában igencsak összetett és kacifántos 
módon jön létre. 


Lepenye Tamás, MCSE 2000 
lepenyetemal.hu 


Felhasznált és ajánlott irodalom 
Windows 2000 Server Internetworking Guide 
Chapter 3: IP Unicast j 
Chapter 7: Remote Access Server 
Windows 2000 TCP/IP Core Networking Guide 
Windows 2000 Help — RRAS 
Windows 2000 Help — DHCP 
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Active Directory Hpplication 
Mode 


Címtárat mindenkinek! 


§i 


7 





ö Az ADAM használatával többé nincs szükség egyedi címtárszolgáltatásra speciális, esetleg belső fej- 
a lesztésű alkalmazásaink számára sem, mivel az ADAM messzemenően képes alkalmazkodni bármi- 
lyen feladathoz. Minden ezt igénylő alkalmazás önálló, de az Active Directory-val együttműködő cím- 


. Címtárat mindenkinek! ? I 


Active Directory Application Node 
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tárat használhat egyedi sémával és replikációs beállításokkal. 


Bevezetés 


A Lightweight Directory Access Protocol (LDAP) alapú megol- 
dások terjedésével, a 90-es évek közepén a vállalatok olyan 
üzleti szolgáltatásokat vezettek be, amelyek valamilyen cím- 
tár használatával valósították meg például a hálózati azonosí- 
tást és engedélyezést, a nyilvános kulcsok terjesztését, és az 
üzleti alkalmazások számos más speciális funkcióját. 
Ennek eredményeképpen sok vállalatnál állt elő az a helyzet, 
hogy minden említett funkció támogatását külön címtár vég- 
zi, ráadásul az sem ritka, hogy ezek különböző címtár-tech- 
nológián alapulnak. Például a hálózati bejelentkezéseket ke- 
zelheti a Microsoft Active Directory, a nyilvános kulcsok ter- 
jesztését X.500 címtár, az üzleti alkalmazások pedig hasz- 
nálhatnak egy harmadik technológiát. 





Miért is van több címtárunk? 


Mivel minden címtár az LDAP-protokollon alapul, jogosan 
merül fel a kérdés, hogy miért nem használnak ezek a válla- 
latok egyetlen közös címtárat minden funkció számára? A 
válasz éppen azokban a tényezőkben rejlik, amelyek a hely- 
zet kialakulásához vezettek: 

A A címtárak közötti együttműködés hiánya — Számos 
címtárszolgáltatás létezik, amelyek nem képesek az 
együttműködésre. Például az eredeti X.500 címtárak 
az LDAP-protokollt sem támogatják, és még ma is szá- 
mos olyan, címtárat is megvalósító termék készül, 
amelyek nem támogatják az LDAP-t, vagy más széles 
körben használt protokollt. 

mA A választási lehetőség hiánya — Ma is kaphatók olyan 
megoldások, amelyek nem képesek az összes haszná- 
latos címtárszolgáltatással együttműködni, ezek vásár- 
lói rákényszerülhetnek olyan címtárszolgáltatás beve- 
zetésére, amelyet korábban még nem használtak. 

A A koordináció hiánya — Bizonyos esetekben a vállalat 
különböző csoportjai egymástól függetlenül különböző 
megoldásokat, és ezzel együtt különböző címtár-tech- 
nológiákat vesznek használatba. 

AA A biztonsággal kapcsolatos együttműködés hiánya — Az 
üzleti alkalmazások ritkán teszik lehetővé, hogy azo- 
nosítási adataikat tőlük független címtár tárolhassa, így 
tehát a megvásárolt új alkalmazás ,hozza" a saját cím- 
tárát. 


Problémák a címtárakkal 


Egyre több vállalat érzi azonban a helyzet tarthatatlanságát, 
elsősorban a következő okok miatt: 

Hi Nagyobb biztonsági kockázat — A címtárfüggő alkalma- 

zások szaporodásával egyre nehezebbé válik a címtá- 

rak közötti hatékony szinkronizáció. 

Elengedhetetlen, hogy a vállalattal 

kapcsolatba kerülő, vagy kapcsolatu- 


Az alkalmazásokhoz kat megszakító munkavállalók, part- 
, . nerek, megrendelők hozzáférése a 
tartozó egyedi vállalat hálózatához, és a különböző 


alkalmazásokhoz, hatékony és biz- 
tonságos módon legyen szabályozha- 
tó. Ha a hozzáférés megadása lassú és 
körülményes, az csökkenti a termelé- 
kenységet, a hozzáférés megszünteté- 
sének esetleges elmaradása vagy ké- 
sése pedig jelentős biztonsági kocká- 


címtárak szaporodása 
számos problémát vet 


fel, és jelentős 


többletköltséggel zatot jelenthet. 
s A Magasabb költségek — Minden 
járhat. üzleti alkalmazás, amely önálló 


címtárszolgáltatást használ, igényli az 

adott technológiára kiképzett" sze- 
mélyzetet, valamint egyedi üzemeltetési és felügyeleti 
folyamatok kidolgozását. 

AA Az üzleti folyamatokkal való integráció hiánya — A cím- 
tár-információknak az üzleti folyamatoknak megfele- 
lően folyamatosan változniuk kell. Ha az adatokat több 
különböző címtárban kell párhuzamosan módosítani, 
automatizált eljárás nélkül szinte reménytelen feladat a 
konzisztencia hosszú távú fenntartása. 


A vállalatoknak olyan címtármegoldásra van szükségük, 
amely alkalmas a hálózati infrastruktúra, és az önálló alkalma- 
zások igényeinek együttes kezelésére. Az Active Directory ki- 
válóan alkalmas erre a feladatra, méghozzá újabb licenckölt- 
ségek és az új címtárszolgáltatás bevezetésével kapcsolatos 
költségek nélkül. 

Az Active Directory Application Mode (ADAM) az Active 
Directory új szolgáltatása, amely a címtárat használó alkalma- 
zások bevezetésekor számos különféle helyzetben előnyösen 
használható. 


Az ADAM nemcsak a tartományvezérlőkön, hanem a tagki- 
szolgálókon, vagy önálló gépeken is futtatható, sőt több pél- 
dányban is elindítható, és a példányok mindegyikéhez önálló 
beállításokat adhatunk meg. 


Címtár alkalmazásoknak 


Sok alkalmazásnak csak egészen egyszerű címtárra van szük- 
sége. A tárolt információkat általában csak szűk körben kell 
elérni, és nincs szükség a teljes szervezetre kiterjedő repliká- 
cióra sem. Az alkalmazások kiszolgálása más szolgáltatási 
módot igényel, mint a Network Operating System (hálózati 
operációs rendszer, NOS) objektumaira vonatkozó adatok tá- 
rolása. Például, ha az alkalmazások adatainak gyakori repliká- 
cióra van szüksége, a NOS-objektumokkal együtt történő tá- 
rolás jelentős terhelést jelenthet a teljes adatbázis sűrűbb rep- 
likálása miatt. Ilyen esetben az ADAM biztosíthatja az alkal- 
mazások egyedi igényeinek megfelelő tárolást. 
Az alkalmazások címtárai folyamatosan fejlődhetnek, változ- 
hat a séma és a beállítások, hogy mindig megfelelhessenek a 
változó üzleti igényeknek. Az ADAM példányok külön-külön 
módosíthatók, nincs szükség egy alkalmazás igényei miatt a 
teljes vállalat címtár-struktúrájának megváltoztatására. 
Az ADAM kiválóan felhasználható a következő feladatok 
megoldására: 

1 Alkalmazás-specifikus címtárak 

m Címtáralapú alkalmazások fejlesztése 

A Az extranet hozzáférés felügyelete 

MH Migráció 


Alkalmazás specifikus címtárak 


Tekintsünk egy alkalmazást, amelynek tárolnia kell a NOS 
Active Directory által azonosított felhasználók bizonyos spe- 
ciális adatait. Ha az adatok közvetlenül a NOS címtárba ke- 
rülnének, a teljes szervezetre kiterjedő sémamódosításra len- 
ne szükség. Ebben az esetben a jó megoldás az, ha a felhasz- 
nálók azonosítását továbbra is az Active Directory végzi, a 
speciális adatok tárolását pedig az ADAM-re bízzuk. Ebben az 
esetben az Active Directory felhasználó-azonosítási rendszere 
végzi az ADAM objektumokhoz való hozzáférési jogok kont- 
rollját. 
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E Az alkalmazás specifikus adatokat az ADAM elkülöni- 
tetten tárolja 


Az ADAM olyat tárolóhelyet biztosít az alkalmazás számára, 
ahol a , privát" adatait elkülönítetten tárolhatja, a NOS Active 
Directory bármiféle módosítása nélkül. Ilyen módon elkerül- 
hető az adatok teljes körű replikációja is — az ADAM címtár- 
hoz önálló replikációs beállítások adhatók meg. Az ADAM se- 





gítségével a címtáralapú alkalmazások, akár teljesen 
egyedi adatbázis sémát használhatnak adataik táro- 
lására. 

Az ADAM segítségével lehetővé válik az is, hogy a 
vállalat egyes szervezeti egységei az általuk kizáró- 
lagosan használt alkalmazás ADAM címtárát teljesen önál- 
lóan felügyeljék, maguk határozzák meg például a replikáció 
ütemezését. 

Lehetőség van azonban arra is, hogy az ADAM példányok 
felügyeletét is a központi IT részleg végezze. A központi 
felügyelet alatt álló kiszolgálón lévő ADAM példányok tulaj- 
donságai egymástól függetlenül állíthatók be. Az ADAM pél- 
dányok mindegyike másik címtáralapú alkalmazáshoz tartoz- 
hat. 

Az ADAM használatával a címtáralapú alkalmazások Win- 
dows NT 4.0 tartományokban is használhatók. Az ADAM eb- 
ben az esetben a Windows NT 4.0 tartomány tagjaként telepí- 
tett Windows Server 2003 kiszolgálóra kerülhet, és mivel az 
ADAM a Windows biztonsági architektúráját használja, a fel- 
használók azonosítását a Windows NT 4.0 tartomány is el 
tudja végezni. 


Címtáralapú alkalmazások fejlesztése 


Az ADAM kiválóan alkalmas az Active Directory alapú alkal- 
mazások prototípusainak üzemeltetetéséhez, mivel az Active 
Directory-val megegyező programozási és felügyeleti modellt 
használ. Így a fejlesztők a saját számítógépükre telepített 
ADAM példányokkal dolgozhatnak, majd az elkészült alkal- 
mazás egyszerűen átvihető az Active Directory-ba. 

Az ADAM telepítése nagyon egyszerű, a telepítő csak mini- 
mális adatbevitelt igényel. A fejlesztők akár több különböző 
módon beállított és különböző adatokat tartalmazó ADAM 
példányt is használhatnak a fejlesztés alatt, a példányok kö- 
zötti váltáshoz, még a számítógép újraindítása sem szükséges. 
Az ADAM-et nem kell kiszolgálóra vagy tartományvezérlőre 
telepíteni, hatékonyan működtethető a fejlesztők saját számí- 
tógépein, az alkalmazások fejlesztése és tesztelése a rendszer- 
gazdák közreműködése nélkül történhet. Az ADAM haszná- 
latához Microsoft Windows XP, vagy a Windows Server 
2003 Standard, Enterprise illetve Datacenter változatára van 
szükség. 


Az extranet hozzáférés felügyelete 


Az ADAM jól használható az extranet hozzáférés felügyeleté- 
hez is. Az ADAM képes olyan felhasználói objektumok táro- 
lására is, amelyeket nem a Windows hozzáférés-vezérlési 
rendszere azonosít. Az extranethez való hozzáférés felügyele- 
tét ellátó Web portál alkalmazás a felhasználói adatokat az 
ADAM-ben tárolhatja, és ezek segítségével végezheti el a fel- 
használók azonosítását. 
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7 Ez a felállás heterogén környezetben is működőké- 


pes, sőt akkor is, ha NOS Active Directory-t egyálta- 
lán nem használunk. A webes ügyfeleket kiszolgáló 
portál alkalmazás tehát bármilyen platformon futhat, 
míg az ADAM-et egyszerűen mint LDAP elérhető- 
séggel rendelkező tárolót használja. 

Migráció 

Az ADAM felhasználható arra is, hogy a vállalat meglévő cím- 
tárát fokozatosan cserélje le az Active Directory-ra. Számos 
vállalat használ meglévő alkalmazásai kiszolgálásához X.500 
alapú címtárat. Az Active Directory bevezetéskor az ADAM 
felhasználható az X.500 elnevezési struktúrát igénylő alkal- 
mazások átmeneti kiszolgálására. 

A NOS Active Directory biztosítja a szervezet megosztott biz- 
tonsági infrastruktúráját, míg az ADAM tárolja a régebbi alkal- 
mazások adatait. Ezután a régebbi alkalmazások cseréje foko- 
zatosan valósítható meg. Az Active Directory és az ADAM 
szinkronizáláshoz köztes címtárat használhatunk, amelyet 
például a Microsoft Metadirectory Services 2003 biztosíthat. 
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E Migráció Active Directory-ra 


Az ADAM tulajdonságai és szolgáltatásai 


Ezután sorra vesszük az ADAM használatával és felügyeleté- 
vel kapcsolatos legfontosabb eszközöket és tudnivalókat: 

Az ADAM részei 

Testreszabás, bővítés 

Replikáció 

Telepítés és eltávolítás 

Több példány támogatása 

Biztonsági mentés és helyreállítás 

Felügyeleti eszközök 

Biztonság 


BBEBBBBBBB 


Az ADAM részei 


Az ADAM a címtárat megvalósító szolgáltatásból (ennek kód- 
bázisa megegyezik az Active Directory-val), a hozzá tartozó 
adatbázisfájlból, valamint a hozzáférést biztosító csatolófelü- 
letekből áll. 


B 


Címtár Csatolófelületel 
szolgált. tás  [(LDAP, 
(dsamain.exe) freplikáció) 





címtár- 
ügyfél 
Címtár 
adatbázis 
(adamntds.dit) 

A 

s 

ADAM 

kiszolgáló 


ni 


E Az ADAM felépítése 


Testreszabás, bővítés 


Az ADAM támogatja a rugalmasan bővíthető adatbázis-séma 
használatát. A séma testreszabására a szokásos Active 
Directory eszközökre alapuló programok állnak rendelkezés- 
re, például az Idifde, az ADAM Schema beépülő modul, vagy 
az ADAM ADSI Edit. Az egy gépen belül futó ADAM példá- 
nyok is önálló sémával rendelkezhetnek. 

Minden egyes ADAM példány több adatpartíciót tartalmazhat, 
amelyekre önálló tárolási, terjesztési és replikációs beállítások 
adhatók meg. A tároló biztosítja a rugalmas névhasználat le- 
hetőségét is, használhatunk DNS vagy X.500 rendszerű elne- 
vezési struktúrát is. 

Replikáció 

Az ADAM az Active Directory-val megegyező multi-master 
replikációs modell szerint működik, így az adatok a repliká- 
cióban részt vevő bármelyik adatbázisban módosíthatók. Az 
ADAM hasonlóan az Active Directory-hoz lehetővé teszi a te- 
lephelyek közötti replikáció ütemezését és az átvitt adatok tö- 
mörítését is. 

Ha az alkalmazások adatait az Active Directoryban tároljuk, 
azok replikációja csak a NOS adatokkal együtt történhet. Az 
ADAM használatával az alkalmazások adatainak replikációja 
azok speciális igényeinek megfelelően is ütemezhető. 
Természetesen lehetőség van akár egy gépen belül az ADAM 
példányok közötti replikációra is. 


Telepítés és eltávolítás 
Az ADAM a Windows Server 2003 kiegészítő komponense, a 
Microsoft külön csomagban terjeszti azt. A csomag letölthető 
az [adam] címről. Négy letölthető fájl közül választhatunk, a 
szoftver létezik x86 és IA64 platformra, valamint van végfel- 
használói (retail) és viszonteladói (redistributable) változat is, 
amelynek licence lehetővé teszi, hogy az általunk készített al- 
kalmazásokhoz csomagolva továbbadhassuk azt. 
Az ADAM a szokásos Windows alapú telepítőprogramot hasz- 
nálja. Csak minimális adatbevitelre van szükség, és a telepítés 
egy script használatával könnyen automatizálható, így lehető- 
ség van az ADAM használó alkalmazással együtt történő, tel- 
jesen beavatkozás nélküli telepítésre is. 
A telepítő varázsló lehetőséget nyújt új példány, illetve meglé- 
vő példány replikájának létrehozására is. 
Az eltávolító varázslóval a következő feladatokat végzi el: 

A A kijelölt ADAM példányok törlése 

AA A beállítási adatokat tartalmazó fájlok törlése 

A Partíciók törlése 





Az egyszerű telepítés és eltávolítás időt takarít meg a rendszer- 
gazdák számára, és megkönnyíti az ADAM átvitelét a teszt- 
környezetből a felhasználás helyére. 


Több példány támogatása 

Egyetlen kiszolgálón több ADAM példány futtatható egy idő- 
ben. A példányok teljesen elkülönítetten működnek, minden 
beállításuk egymástól függetlenül adható meg. Minden ADAM 
példány egyedi névvel és portszámmal azonosítható. 

A több ADAM példány futtatásának lehetősége jelentős elő- 
nyökkel járhat a vállalat számára, lehetővé teszi a kiszolgálók 
egyesítését, könnyebbé teszi az üzleti alkalmazások fejleszté- 
sét, és az alkalmazások frissítésének végrehajtását. 

Az egyes példányok a hozzájuk csatlakozó alkalmazások spe- 
ciális igényeinek megfelelően állíthatók be, és az alkalmazá- 
sok több különböző adattárral is együttműködhetnek. 


Biztonsági mentés és helyreállítás 

Az ADAM biztonsági mentése és helyreállítása a Windows 
operációs rendszer szokásos eszközeivel végezhető el. Min- 
den példány könnyen automatizálható online folyamat kere- 
tében menthető, így a kritikus adatok minden körülmények 
között könnyen és gyorsan hozzáférhetők lesznek. Az 
NTBackup segédprogram lehetővé teszi az ADAM példányok 
online mentését és offline helyreállítását. 


Felügyeleti eszközök 


Mivel az ADAM az Active Directory egy üzemmódjának te- 
kinthető, a felügyelet az Active Directory-hoz hasonlóan, az 
ismert felügyeleti eszközök módosított változataival végezhe- 
tő el. Az ADAM felügyeleti eszközei az alkalmazással együtt 
kerülnek telepítésre: 

m Ldp (Ldp.exe) — az Idp segítségével (ami grafikus fel- 
használói felülettel működik) LDAP műveleteket vé- 
gezhetünk az ADAM címtáron. 

MA Az ADAM ADSI Edit az ismert ADSI Edit eszközön 
alapul, és lehetővé teszi a címtár valamennyi objektu- 
mának (a sémának és a beállítási adatoknak is) megje- 
lenítését, az objektumok módosítását és a hozzáférés 
vezérlési listák szerkesztését. 

mA A szokásos monitorozó eszközök (például a Perfmon) 
használhatók az ADAM-mel kapcsolatos hálózati és 
rendszerteljesítmény nyomon követésére. Minden 
egyes ADAM példány teljesítményadatait naplófájlok- 
ba gyűjthetjük, és a Microsoft Management Console 
(MMC) változatos megjelenítési képességeit felhasz- 
nálva elemezhetjük azokat. 

H A Dsadmin és a dsdbutil (az ntdsutil-hoz hasonló) 
használható az adatbázis karbantartásához, az egyedi 
főkiszolgáló-műveletek (single master operation) vég- 
rehajtásához, és a címtár-partíciók létrehozásához. 


Jelentős megtakarítással járhat, hogy az Active Directory-hoz 
nagyon hasonló ADAM felügyeleti eszközök használatához 
nincsen szükség külön képzésre. 


Biztonság 


Az ADAM szorosan illeszkedik a Windows operációs rend- 
szer biztonsági modelljébe. Az ADAM-ben tárolt objektumok- 





hoz és a szolgáltatáshoz magához a következők fér- 
hetnek hozzá: 
A A NOS Active Directory-ban szereplő fel- 
használók 
A A Windows NT 4.0 tartományban szereplő 
felhasználók 
A A helyi számítógépen felvett felhasználói fiókok 


Az ADAM támogatja továbbá az LDAP alapú hitelesítést kül- 
ső biztonsági infrastruktúra használatával. Létrehozhatunk fel- 
használói fiókokat az ADAM-en belül is, így az alkalmazások 
a címtárra bízzák a hitelesítést, míg a jogok kiosztását maguk 
végzik el. Ebben az esetben az ADAM a hitelesítést egysze- 
rűen az LDAP csatolás segítségével végzi el. 

A címtárobjektumokhoz való hozzáférés szabályozása a Win- 
dows meglévő hozzáférés vezérlési listáinak (Access Control 
List, ACL ) felhasználásával történik. Ilyen módon lehetőség 
van a hozzáférés részletes szabályozására valamennyi ADAM 
példány minden objektumára vonatkozóan. Az alkalmazások 
tovább bővíthetik a hozzáférés szabályozás lehetőségeit saját 
keretrendszer felhasználásával, míg a felhasználók hitelesíté- 
sét továbbra is a címtár végzi. 


Összefoglalás 


Azok a vállalatok és fejlesztők, akiknek címtárszolgáltatásra 
van szükségük alkalmazásaik számára, az Active Directory új, 
kiegészítő szolgáltatása révén számos előnyhöz juthatnak: 

A Egyszerű telepítés — A fejlesztők és végfelhasználók 
könnyen telepíthetik LDAP szolgáltatásként a Win- 
dows 2003 Server különféle változataira és a Windows 
XP-re. Az ADAM telepítése, újratelepítése és eltávolí- 
tása könnyen automatizálható, így kiválóan megfelel 
az alkalmazással együtt terjesztett címtárszolgáltatás 
céljára. 

A Alacsonyabb infrastrukturális költségek — Ha egységes 
címtár-technológiát használunk az alkalmazásokhoz 
és a hálózat objektumaihoz, csökkenthetőek az infra- 
struktúra fenntartásával és a felügyeletet végző sze- 
mélyzet képzésével kapcsolatos költségek. 

A Magasabb biztonsági szint — A Windows biztonsági 
modelljével való integráció lehetővé teszi minden 
ADAM-et használó alkalmazás számára, hogy a fel- 
használók hitelesítését a vállalati Active Directory-ra 
bízza. 

A Nagyobb rugalmasság - A fejlesztők könnyen készít- 
hetnek címtáralapú alkalmazásokat anélkül, hogy a 
vállalat címtár-sémáját módosítani kellene. 

A Megbízhatóság és skálázhatóság — Az ADAM-et hasz- 
náló alkalmazások az Active Directory-nál megismert 
megbízhatóságot, skálázhatóságot és teljesítményt 
kapják az adataikat tároló címtártól. 


Az ADAM segítségével egyetlen címtár-technológiát használ- 
hatunk a vállalatnál előforduló minden címtárat igénylő 
feladat megoldására. 


Szerényi László 
szerenyi.lomet.hu 
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Tanúsítványukiadók a 
Windowsban 


Kulcsarchiválás és -helyreállítás, 
adatmentés, Certificate Trust List 


A Windows Server 2003, Enterprise Edition tanúsítványkiadó szolgáltatása segítségével biztonságosan 
tárolhatók és szükség esetén vissza is tölthetők a felhasználók privát kulcsai. Cikkünkben kitérünk még 
a tanúsítványkiadó adatbázisának biztonsági mentésére, valamint a tanúsítványláncok összekapcsolá- 


sának egyik módjára. 


Miért van szükség a privát kulcsok biztonsági jellegű táro- 
lására? 

Nem téved, aki úgy tudja, hogy a nyílt kulcsú biztonsági 
architektúrában a felhasználó privát kulcsa csakis a felhaszná- 
lóé, ahhoz senki más, semmilyen formában nem férhet hozzá. 
A privát kulcs titkosítva a felhasználó profiljában, biztonságo- 
sabb megoldásoknál hardveres kulcstároló eszközön találha- 
tó, utóbbit a kulcs még ,erőszakkal" sem hagyja el. Ott kelet- 
kezik, és ott is éli le teljes életét. 

A felhasználó privát kulcsának megsemmisülése azonban ko- 
moly következményekkel járhat. Ha a kulcshoz tartozó tanú- 
sítványt digitális aláíráshoz használtuk, még nem túl nagy a 
gond (egy új kulcspárral és tanúsítvánnyal továbbra is írhatunk 
alá digitálisan, bár az új kulcs publikus felét, azaz az új tanú- 
sítványt közzé kell tenni és eljuttatni a digitális aláírást el- 
lenőrző partnerekhez). Ha viszont a megsemmisült kulcspárt 
titkosításhoz használtuk, nagy a baj: minden adatot a megsem- 
misült privát kulcs publikus párjával titkosítottunk, így azt csak 
a privát kulcs segítségével lehet(ne) visszaállítani. A titkosító 
kulcspár privát felének elvesztése tehát automatikusan a titko- 
sított adatok elvesztését is jelenti! (Éppen ezért nem szokták a 
titkosító kulcspárt olyan hardvereszközön tárolni, ahonnan ka- 
tasztrófa esetén sem lehet kiexportálni. Különben, ha elveszik 
az eszköz — átmegy rajta a villamos —, elvesznek az adataink.) 


Központi kulcstárolás 


A megoldás az, hogy - ha a privát kulcs exportálható —, a fel- 
használó saját munkamenetéből, saját magának, jelszóval vé- 
dett és titkosított .pfx fájlba exportálhatja a tanúsítványt és a 
hozzá tartozó kulcspárt. Így az később a jelszó ismeretében 
bármikor visszaállítható. 

Ahogy azonban a PKI megoldások világszerte egyre inkább 
terjednek, úgy lesz egyre nagyobb azon felhasználók száma, 
akinek a tanúsítvány exportálása már túl nagy, már-már 
megoldhatatlan feladatot jelent. Az ,átlagos" felhasználó ké- 
pes arra, hogy bekattintsa a levelezőprogramjában a levél di- 
gitális aláírására vagy titkosítására utaló opciót, de általában — 
és sajnos — ismeretlen számára a tanúsítványok, kulcsok, tanú- 
sítványkiadók világa. Nem véletlen, hogy a Windows Server 
2003 Enterprise Edition tanúsítványkiadói már támogatják az 
automatikus tanúsítványkiadást (az előző részekben már ejtet- 
tünk szót erről). A következő lépés, bármilyen furcsán hangzik 


is, a felhasználók privát kulcsainak központosított, biztonsá- 
gos tárolása. 

Ebben az esetben a felhasználók privát kulcsai a tanúsítvány- 
kiadó adatbázisába is bekerülnek. A biztonsági szempontból 
legfontosabb kérdés, hogy milyen formában történik ez az 
adattárolás, mi az, ami megakadályozza, hogy a felhasználók 
privát kulcsai illetéktelen kezekbe kerüljenek? 


A kulcshelyreállító ügynök 


A bekezdéscím elárulja: a biztonságot nem , mi", hanem ,ki" 
garantálja. Amikor a felhasználó olyan tanúsítványt kér, 
amelynek sablonjában bekapcsoltuk a privát kulcsok archivá- 
lását, a tanúsítványkiadó szervezet a felhasználó (számítógé- 
pének) elküldi a kulcshelyreállító ügynök(ök) (Key Recovery 
Agent kifejezetten erre a célra készült, kulcshelyreállító tanú- 
sítványának publikus kulcsát. A felhasználó az ügynök publi- 
kus kulcsának segítségével titkosítja a saját privát kulcsát, 
majd elküldi azt a tanúsítványkiadónak, ami a titkosított ada- 
tot tárolja az adatbázisban. Az adatbázisban tárolt felhaszná- 
lói privát kulcs csakis a kulcshelyreállító ügynök tanúsítványá- 
nak privát kulcsa segítségével nyerhető ki. A kulcshelyreállító 
ügynök tehát bizalmi állás (akárcsak az EFS titkosított fájlok 
helyreállítására képes ügynöke, a File Recovery Agen0). 

A kulcshelyreállító ügynök tanúsítványát egy speciális tanúsít- 
ványsablonból (Key Recovery Ageni) készítjük. A Windows ta- 
núsítványkiadó telepítés után automatikusan ilyen sablonból 
tanúsítványt nem ad ki, ezért ,kézzel" fel kell vennünk azt a 
kiadható tanúsítványsablonok közé: 





Ele Action Yew 
.- mm BB é 
[DJ certőcation Authortty (Local) Name 
5 ÉJ Falotrax CA lazsenrolment User 
E Rávalad Catfteskás dörectory Emal Replcation 
CI tatued Contficatos JDomain Controller Authenttication 
I Pendng Regvests KG tzezágttáji 
I FaledRegvests et 
keltés MLANENÉSESEL Tzdnoman Controlar 











Intended Purpose 
lent Authenticatlon, Secure Emi 
Directory Service Email Replcatior 
Cllent Authentication, Server Autl 
Fe Recovery 
Enerypting File System 
Clant Authanticatián, Sarvar Art 








I Enable Certificate Templates T 21x] 
"elect one or more Certihcate T emplates lo enable on this Certiíication Authority 
Name 2] 










[zdRAS andlas Ser 
[d Roer tÖlténe regvest) 
[d smartcsrd Logon 
[dSmancard User 


Setvet Authentication 
Cbent Athentication 

Cent Authentication, Smart Card Logon 
Secure Emöl Cent Authenticaton. Smart Card Lonon 


B A cKey Recovery Agent tanúsítványsablon felvétele 





Miután ezzel megvagyunk, következhet a tanúsítványkérés. A 
kulcshelyreállító ügynök(ök) személye cégenként más és más 
lesz, de azt mindenképpen vegyük figyelembe, hogy ez a tu- 
dás tényleg hatalom, hiszen segítségével bármely felhasználó 
privát kulcsához hozzá lehet férni. Miután kijelöltük az ügy- 
nököket, a megszokott módon kérjünk részükre Key Recovery 
Agent tanúsítványt! 





fir Certificates - (Console RootiCertificates - Current As 


Én Ele  Adtion  Wew  Favortes Window . Help 
ASP [ED fEg d [TA [8 e éa a Esti 
[dssved To Issuedgy — /Expíration Date — ] Intended Purposes — [Fri 
jatrator  Adtmínistratot 2006, 04.20. FieRecovery an 
(administrator Falatrax CA — 2005.07.21 Key Recovery Agent eh 











( Console Root 
7 ÉJ Certíícates - Current User 
A CI Personal 
XI Certificates 
vi I Trústed Root Certficatic 
8 (I Enterprise Trust 













B Key Recovery Agent tanúsítvány az ügynök profiljában 


A következő lépésben a tanúsítványkiadó szolgáltatásba kell 
feltöltenünk a kulcshelyreállító tanúsítvány publikus kulcsát. 
A tanúsítványkiadó ezeket a tanúsítványokat küldi majd el a 
felhasználónak, aki majd a bennük található publikus kulccsal 
titkosítja a saját privát kulcsát és küldi el a tanúsítványkiadó 
adatbázisába. A Key Recovery Agent ügynökök telepítése a 
Certification Authority eszközben, a tanúsítványkiadó tulaj- 
donságlapjának Recovery Agents oldalán végezhető el: 


Falatrax CA Properties já 212 


General ]  Poligy Module ] ExitModule ] Extensions ] Storage ] 
Certificate Managers Restrictions ] Auditing Recovery Agents ] Security l 


Do the following when a certificate reguest includes key archival; 
C Donot archive the key 
G Archivethe key 

Number of recovery agents to use: 

He 

Key recovery agent certificates: 


[dssuer —— [/ Expiratin Date — Í Status 


(edádrministrator  Falatrax CA 2005. 07.21. 22.50 Valid 





ol 
Add... Remove [ve 








E Kulcsarchiválás és Recovery Agent tanúsítványok beál- 
lítása a tanúsítványkiadó szolgáltatásban 


Ne ijedjünk meg, ha a felvett tanúsítványok státusza először 
sNot loaded". Az Apply gombra kattintva a konzol újraindítja 
a tanúsítványkiadó szolgáltatást, és legközelebb már a , Valid" 
státusszal fogunk találkozni. 

Ha megnézzük a tanúsítványkiadó szolgáltatást futtató számí- 
tógép tanúsítványtárát, ott a KRA mappában láthatjuk is a be- 
töltött tanúsítványokat. Ha egy ilyen tanúsítványt megnyitunk, 
az is látszik, hogy a gép nem rendelkezik a tanúsítványhoz 
tartozó privát kulccsal. 

Miután a tanúsítványt betöltöttük, még egy dolgunk van: fon- 
tos, hogy ha a kulcshelyreállító tanúsítványt nem valamilyen 


tech.net W4átT KÁRT. w 


hardvereszközön tároljuk, a kulcshelyreállító ügy- 
nök profiljából privát kulccsal együtt exportáljuk, 
majd töröljük a kulcshelyreállító tanúsítványt. A 
kiexportált .píx fájlt tároljuk biztonságos helyen (pél- 
dául egy páncélszekrényben), hiszen arra csak akkor 
lesz szükség, ha egy archivált privát kulcsot helyre kell állíta- 
nunk. 

Ezzel a tanúsítványkiadó kész a kulcsok archiválására. 


Kulcsarchiválás bekapcsolása a tanúsítványsablonban 


A tanúsítványkiadó csak olyan tanúsítványok esetén menti a 
felhasználó privát kulcsát, amelyek sablonjában ezt a szolgál- 
tatást kifejezetten bekapcsoltuk. Miután itt a tanúsítványsablo- 
nok szerkesztéséről van szó, rögtön látható, hogy a kulcs- 
archiválás csakis az új, v2-es tanúsítványsablonokkal, 
Windows Server 2003 Enterprise Edition kiszolgálóra telepített 
tanúsítványkiadó szolgáltatás esetén működik. 

válasszunk tehát egy tanúsítványsablont (példánkban a koráb- 
ban automatikus kiadásra már előkészített Autoenrollment 
User sablont használjuk erre), és nyissuk meg a sablon tulaj- 
donságlapjának Reguest Handling oldalát! 





Merse states a] 2] 
Issuance Reguirements l Superseded Templates l Extensions l Security ] 
General Reguest Handling Subject Name 
Purpose: Brest kal tel) 





[7 Archive subjects encryption private key 
[7 Include symmetric algoríthms allowed by the subject 
FT Delete revőked or ex 


cates (do not arckivej 





- A Kkulcsarchiválás bekapcsolása a tanúsítványsablonban 


Ezzel készen is vagyunk. A sablonból készült tanúsítványok 
kérésekor a tanúsítványkiadó automatikusan archiválja a pri- 
vát kulcsokat. 


Kulcshelyreállítás 


Tegyük fel, hogy bekövetkezik az első katasztrófa: a felhasz- 
náló elveszíti a privát kulcsot (törlődik a profilja, vagy mond- 
juk a Smart Cardja beleesik a WC-be..). A helyreállításhoz 
szükségünk lesz a kulcshelyreállító ügynökökre (pontosabban 
a tanúsítványaikra). Jelentkezzünk be a tanúsítványkiadó ki- 
szolgálóra, és töltsük be az összes szükséges kulcshelyreállító 
tanúsítványt. A privát kulcs helyreállításához két eszköz áll 
rendelkezésünkre, ezek közül az első a minden CA-n megta- 
lálható certutil parancs. 


A helyreállítás két lépésből áll: 

A Először meg kell keresnünk a tanúsítványkiadó adatbá- 
zisában a megfelelő titkosított adatcsomagot (blob), 
majd elmenteni azt 

AA Ezután a kulcshelyreállító tanúsítvány segítségéből az 
elmentett blob-ból kinyerni a kulcsot és .píx fájlba 
menteni azt. 


Az első lépésre azért van szükség, mert az adatbázisban adott 
esetben többezer elmentett privát kulcs is lehet. Ezek közül 
kell kiválasztanunk azt az egyet, amit keresünk. Ehhez a 
certutil —getkey parancsot használjuk: 





Et 


MEGSMORULM RO YOPPIYÁNPENIISNNE] / 


úg 


Tanúsítványkiadók a Windowsban / 


éb 


A -getkey opció utáni első paraméter a keresett tanúsítvány 
azonosítója, ez lehet: 

a tanúsítványban tárolt Common Name 

a tanúsítvány sorozatszáma (Serial Number) 

a tanúsítvány azonosító hash-e (Thumbprint) 

a tanúsítványt kérő felhasználó neve (domain wsernév 
formában) 

a tanúsítványt kérő felhasználó UPN neve 
(usernév(odomain formában) 


8 B8EBB 


A második paraméter egy fájlnév, ahova sikeres keresés esetén 
a bináris adatok kerülnek majd. (Részletesebb információkat a 
certutil -getkey -? parancs segítségével kaphatunk). Ha a biná- 
ris fájl elkészült, következik a dekódolás a certutil -recoverkey 
parancs segítségével: 


C:Nxcertutil -recoverkey -p titok tesztcert.bin 
tesztcert.pfx 


A -p kapcsoló után megadhatjuk a leendő .pfx fájl titkosítás- 
hoz használt jelszót (itt: , titok"), majd a bináris adatot tartal- 
mazó fájl neve, azután pedig a létrehozandó .píx fájl neve kö- 
vetkezik. Ha a kulcshelyreállító tanúsítvány(ok) elérhetők, a 
parancs dekódolja a privát kulcsot és létrehozza a .píx fájlt, 
amit már csak el kell küldenünk a felhasználónak, aki impor- 
tálhatja azt. 


Key Recovery Tool 


Ha letöltjük a Windows Server 2003 Recovery Kit Tools 
w2k3rktools] csomagot, egy grafikus eszköz könnyíti meg a 
kulcshelyreállítást: ez a Key Recovery Tool (krt.exe). 

B A CKey Recovery Tool működés közben 








le Help 
Certiication authorty (CAT Sesrch Citeria 
"erver2003 falatrax2003 huAF alattax CA XX) [Reawetter name [donantuseg :] 
Vale 
Select the search ciileria, enler an appropriate value, andthen ebek 
"Search" to display a ket ol matching archíved keyz. [dalatrax 2003Neszt 
úszöte ss] 











ial Number [Subject 
Il 


I Natetore ] Notáter — ] Tempiate Cent Hashíshatj — ] 








To recover a piivate key, select ihe associated certlfcate above and then clek "Riecover" 


ShowKRA Retieve Blob.. )  Decyypt Blob. Recgver 
Status [Food Help 








A Key Recovery Tool is a certutil parancsot használja a háttér- 
ben, a működési elve tehát ugyanaz. Először kiválasztjuk a ta- 
núsítványkiadót (Certification authority), ezután megadjuk a 
keresési feltételeket (Search Criteria, Value). A Search gombra 
kattintva elkezdődik a keresés, és a Certificates listában láthat- 
juk a találatokat. Ezután már csak ki kell jelölnünk a helyreál- 
lítani kívánt tanúsítványt, és a Recover gombra kattintani. Ad- 
juk meg a .píx fájl nevét (ez alapértelmezésben a tanúsítvány 
sorozatszámából készül — okos ötlet), majd a .pfx fájl titkosí- 
tásához szükséges jelszót, és már készen is vagyunk! 


A tanúsítványkiadó biztonsági mentése 
Katasztrófa azonban nemcsak a felhasználónál, de a kiszolgá- 


lón is bekövetkezhet. A tanúsítványkiadó szolgáltatás hely- 
reállításához két nagyon fontos dologra van szükségünk: 


HA A tanúsítványkiadó szolgáltatás tanúsítványára 
A A tanúsítványkiadó adatbázisára 


Ezek mindegyike szerepel a Windows teljes rendszermentésé- 
ben (System State): 





3; Backup Utility - [Untitled] 


Job Edit Wiew Iools Help 
Welcome. Backup ] Restore and Manage Media ] Schedule Jobs ] 


Click to select the check box for any díive, folder or file that you want to back up. 
TI Desktop 
] d My Computer 1] sgáctive Directoty 
5) (Je 35Floppy (A) ) td Boot Files 
§ [ds LocalDuk(C)  ([g EE 
9 (I.2 EN LWSO3VL (D- [ [7] gif COM: Class Registration Database 
EZ System State ]) Bf Registty 
9 OL My Documents ] SLGYSVOL 
7 [82 My Network Places ve8 









15 


A teljes rendszermentés tartalmazza a tanúsítvány- 
kiadó szolgáltatást is 


Rendszerállapotot azonban csak egy-az-egyben lehet vissza- 
tölteni, azaz a Certificate Server esetleges sérülése esetén a 
System State mentés a CA adatbázisa mellett visszatöltené az 
Active Directory, a Registry, és egyebek régebbi állapotát is. Er- 
re nem biztos, hogy szükségünk van, ezért a System State men- 
tés mellett , kézzel" is mentsük el a tanúsítványkiadó adatait: 

HA Exportáljuk (privát kulcsostul) .pfx fájlba a tanúsítvány- 
kiadó tanúsítványát (a számítógép tanúsítványtárában 
megtaláljuk). A .píx fájlt tartsuk zárt, biztonságos he- 
lyen, hogy ahhoz senki ne férhessen hozzá! 

A Rendszeresen készítsünk mentést a tanúsítványkiadó 
adatbázisáról a tanúsítványkiadó konzol Back up CA... 
parancsával! (Ez is tartalmazza a privát kulcsot, a tanú- 
sítványt és természetesen az adatbázist is) 















3tart 


Stop Service 











View 





CII te tet 
CI  Exportlist... Back up CA... pe 


Properties 


Renew CA Certificate. , , 






Help 


E A tanúsítványkiadó adatbázisának mentése 


A tanúsítványkiadó szolgáltatás helyreállítása 


A tanúsítványkiadó adatbázisa a Restore CA... paranccsal ko- 
rábbi mentésből bármikor újratölthető. 

Ha a tanúsítványkiadó szolgáltatást újra kell telepítenünk, a 
telepítés során a Public and Private Key Pair oldalon válasszuk 
ki a Use an existing key opciót, majd az Import... gombra kat- 
tintva importáljuk be a korábban elmentett kulcsot a .pfx fájl- 
ból. A telepítés befejezését követően a tanúsítványkiadó — üres 


adatbázissal — elindul, ezután következhet a Restore CA... pa- 
rancs, és az adatbázis visszatöltése. 


Tanúsítványláncok összekapcsolása 


Tegyük fel, hogy cégünk, az ingatlanépítéssel foglalkozó 
Falatrax Kft. két évre szóló stratégiai partnerséget köt az 
EladLak Virtuális Ingatlanforgalmi Kft-vel (VIKft). A tervek sze- 
rint a biztonságos levelezés érdekében a két cég között digitá- 
lis aláírással, illetve titkosítással felvértezett elektronikus leve- 
lezés zajlik majd. A tanúsítványok kezelése azonban kérdéses: 
hogyan vesszük rá például a Falatrax nyílt kulcsú biztonsági 
architektúráját arra, hogy elfogadja és érvényesnek tekintse az 
EladLak saját CA-i által kiadott tanúsítványokat? Ha a Falatrax 
Trusted Root Certification Authorities listájába felvesszük az 
EladtLak gyökér CA-ját, a dolog működni fog. Csakhogy: eb- 
ben az esetben minden EladLak CA által, ráadásul bármilyen 
célra kiadott tanúsítvány automatikusan érvényes lesz a 
Falatrax-nál, ezt pedig nem szeretnénk. Ha korlátoznunk kell 
egy partner CA által kiadott tanúsítványok érvényességi körét 
és -idejét, a megbízott gyökérkiszolgálóként való felvétel he- 
lyett — Windows 2000-en futó CA-k esetén is — használhatjuk 
a Certificate Trust List (CTL) funkciót. 


AA Certificate Trust List 


A CTL egy digitálisan aláírt lista, amely külső, adott célokra és 
adott időszakban megbízhatónak minősített tanúsítvány- 
kiadók tanúsítványait tartalmazza. (A CTL-t egy általunk meg- 
bízott — célszerűen a saját — tanúsítványláncból származó spe- 
ciális, , Trust List Signing" application policyt tartalmazó -— pél- 
dául Trust List Signing sablonból készült - tanúsítvánnyal kell 
aláírni, ez bizonyítja majd a lista érvényességét). Amikor a ta- 
núsítvány ellenőrzése során eljutunk egy gyökér CA-ig, de az 
nincs benne a megbízott gyökérkiadók listájában, a Windows 
ellenőrzi, hogy nincs-e olyan CTL, ami tartalmazza a kérdéses 
CA-t. Ha van, és a CTL digitális aláírásához használt tanúsít- 
vány érvényes, a kérdéses tanúsítvány is érvényes: de csak az 
érvényesítéséhez felhasznált CTL által meghatározott célokra 
és időszakban. 


2]2d 





General ] Details  Certification Path 


í Certification path 
(7 EladLak Root CA 






E Itt a tanúsítvány még érvénytelen: az EladLak Root CA 
nem szerepel a megbízható gyökértanúsítványkiadók 
között 


CTL-t vállalati szinten (a csoportos házirend segítségével), de 
akár egy különálló számítógépen (Windows XP-n is) definiál- 
hatunk. A vállalati szintű definícióhoz a Group Policy Objek- 
tumban a Computer illetve User csoport Windows Settings2 
Security Settings 2 Public Key Policies 2 Enterprise Trust 
elemhez navigáljunk, majd válasszuk a New... parancsot. Ha 
a saját, tartományon kívüli számítógépünkön szeretnénk vala- 
miért CTL-t létrehozni, indítsunk egy MMC konzolt, majd tölt- 
sük be a Group Policy Object Editor modult. Ekkor a User cso- 
mópont alatt (itt ugyanis csak felhasználónak lehet CTL-je), a 
Windows Settings 2 Security Settings 2 Public Key Policies 





72 Enterprise Trust elemnél hozhatunk létre új CTL-t, ) 
illetve importálhatunk meglévőt. £.] 


Új CTL létrehozásakor Certificate Trust List Wizard 

első oldalán elnevezhetjük a CTL-ünket (ennek csak 
kozmetikai jelentősége van), illetve megadhatjuk a 

CTL érvényességét, és az engedélyezett tanúsítvány-szerepkö- 
röket: 


ESZTERT TE E 


Certificate Trust List Purpose 
You have the option of supplying an identification and a duration for the CTL. You 
must also designate its purposes. 


Type a prefix that identifies this CTL (optional): 
Eladtak CTL 


Valid Duration (optional): 
24 months 0 ) days 


Designate purposes: 
( Server Authentcaton 
CI Ctent Authentcation 
[ Code Signing 
EJ Secure Emai 

(J Time stamping 





ha Add Purpose... 


E A CTL varázsló és a legfontosabb beállítások: érvényes- 
ségi idő és tanúsítvány-szerepkörök 


Ezután ki kell választanunk a megbízott Root CA-kat, majd a 
CTL digitális aláírásához használt tanúsítványt. Végül ha akar- 
juk, időbélyeget is elhelyezhetünk a CTL-ben. 

A példabeli EladLak CTL érvényre jutása után a Falatrax-nál az 
Eladtak Root CA által kiadott, addig érvénytelen tanúsítvá- 
nyok érvényesek lesznek. A tanúsítvány tulajdonságlapján pe- 
dig megnézhetjük az érvényességi láncot, amely tartalmazni 
fogja a CTL-t és az azt aláíró tanúsítványt is: 


Certificate HZ 2] 





General ) Details . Certification Path ] 


r Certification path 

Falatrax CA 
EJ Administrator 

(ÉJ certificate Trust List 

EJ EladLak Root CA 

Sales Sándor 






B CTL in Action: a tanúsítvány immár érvényes. (A CTL 
aláírója az Administrator volt) 


A CTL tündöklése és halála 


A Windows Server 2003 azonban ezen a téren is újat hozott. 
A CTL használata - bár működik — már nem ajánlott, ehelyett 
egy új fogalmat kell megismernünk, ami nagyjából ugyanezt a 
célt szolgálja, mégis sokkal jobb, sokkal összetettebb: ez a 
Oualified Subordination (azaz kb. , minősített altanúsítványki- 
adók"), a következő rész témája. . 


Fülöp Miklós 
mick€inetcom.hu 


A cikkben szereplő URL-ek a Ó 
http://technet.netacademia.net/go?kulcsszó 
címen érhetők el. . ; 
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HTTP és egyéb kiszolgálókat üzemeltet, mindig felmerül az a nem is egyszerű tervezési kérdés, hogy 
hova tegyük a kiszolgálókat? A belső hálózatra, és onnan publikáljuk? Ez a jelenlegi, férges korszak- 
ban veszélyes lehet. Két tűzfal közötti DMZ-be? De hisz az plusz egy vasat igényel! Vagy netán hasz- 
náljuk a háromlábú modellt? Miért ne? 


A bevezetőben felvetett tervezési dilemmát — mint láttuk - 
több szempont szerint oldhatjuk fel. A kérdés csak az: melyik 
ujjamat harapjam? Ha az első megoldás mellett döntünk, és 
kiszolgálóikat egyszerűen kipublikáljuk a belső hálózatról, 
megsértjük azt a szabályt, hogy kéretlen külső forgalmat 
egyáltalán ne engedjünk be. Pedig a leggyakrabban ezt szok- 
ták választani, mert ehhez elég egy tűzfal, két hálózati kártya 
és egyetlenegy publikus IP-cím. Az alábbi ábra ezt az esetet 
szemlélteti: 


Tűzfal Belső hálózat 





/ Internet 








SMTP-kiszolgáló 
CI IP-cím: 10.10.10.10 








E (SMTP) kiszolgáló publikálása a belső hálózatról egy 
tűzfal esetén 


Csakhogy ezzel a lépéssel a publikált szerver felé ugyan, de 
lyukat ütöttünk a falon, amin át idegenek nyomakodhatnak a 
belső hálózatunk felé. Nem véletlen, hogy az ISA Serverben 
pontosan az SMTP, a POP3 és a DNS protokollokra vannak 
betörésdetektáló szűrők: ezeket a portokat szoktuk kinyitni. 
(Nomeg a 3389-es, Terminal Services portot. RDP-szűrő nincs 
az ISA Serverben, más kérdés, hogy ezidáig még nem is lett 
volna rá szükség, mert legyelőrel nincs ismert RDP-támadás.) 
Természetesen a HTTP-forgalom is átesik egyfajta szűrésen, 
mert az meg átmegy a Web Proxy szolgáltatáson, ami azt je- 
lenti, hogy nincs közvetlen kapcsolat a két valódi kommuni- 
káló fél között, minden csomagot átvizsgál és átalakít a proxy. 
Erre ékes bizonyíték lehet az SSL-láncolás, ugyanis az ISA rá- 
vehető arra, hogy a beérkező sima HTTP-ből a belső kiszolgá- 
ló felé HTTPS-t (SSL) csináljon, de ami meglepőbb lehet, en- 
nek a fordítottjára is képes. Kívülről jövő HTTPS-ből sima 
HTTP-t csinál, ha úgy akarjuk. 

Erre nem azért képes, mert ,meghekkeli" a rajta átmenő SSL- 
csatornát, hanem mert nem is megy át rajta a HTTPS — a csa- 
torna nála végződik. 


HMáromlábú [5H JerUer 


DMZ külön hálózaton 


Amikor egy cég ,magához ragadja" az Internetes szolgáltatások körét, és saját SMTP, 


London IIS Properties HE 


General ] Destinations ] Action . Bridging ] Applies To] 
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Redíirect HTTP reguests as: 





C SSL reguests (establish a secure channel to the site) 
C ETP reguests 





fr Redirect SSL reguests as: ————————————— 
] GC HITP reguests (terminate the secure channel at the proxy) 


get SSL reguests (establish a new secure channel to the site) 


! 
! 
] C FTP reguests 





f T Reguire secure channel (SSL) for published site ———— 
FR 








uire 128: 


cryption 














Cancel ápply 





ai 


Hogyan továbbítsuk az SSL-t? Simán? És hogyan a pu- 
cér HTTP-t? SSL-csatornában? 


LAT-olgassunk 


Honnan tudja az ISA, hogy melyik lába ,lóg kifelé"? Ezt a tűz- 
fal telepítésekor mondjuk meg neki a Local Address Table 
(LAT) kitöltésével. A LAT-ba felvett címek jelentik a tűzfal szá- 
mára a belső címeket. Ami nincs bent a LAT-ban, az definíció 
szerint külső cím, tehát hallgass a neve. Tulajdonképpen az 
egész tűzfal mély hallgatásba burkolózik a külső kérések elől 
- amíg valamit ki nem publikálunk. 

Most tételezzük fel a legrosszabbat: a publikált kiszolgálónk 
kívülről elérhető szolgáltatására valaki , kifejleszt" egy ügyes 
buffer overrun támadást, másvalaki pedig férget is fabrikál 
hozzá. Ne nevessünk korán, a januári Slammer pont ezt a for- 
gatókönyvet követte: buffer overrunnal megdöntött egy kívül- 
ről elérhető szolgáltatást, az SOL Server portátirányítóját. És 
már kész is a baj. Ha bejut a féreg, mindjárt a belső hálóza- 
tunkon találja magát, és lesz nemulass! 


GIF-féreg, JPEG-vírus 


Hadd tegyek itt egy kis szakmai kitérőt azok számára, akik 
szerint mindez lehetetlen, mert a támadást vagy megfogja az 
ISA beépített filtere (már amennyiben engedélyezve van), vagy 


mire átvergődik a NAT-on, minden erejét elveszíti, tehát hatás- 
talan lesz. 

Tisztelettel jelentem, hogy feltaláltam a GIF-féregvírust. Ez 
GIF-képállományokban rejtőzik, és oly módon hat, hogy buf- 
fer overrunt okoz a GIF-nézegető alkalmazásban, mondjuk az 
Internet Explorer megfelelő moduljában. Az ötletet ingyen 
adom, már csak egy fejlesztő hiányzik, aki megírja. 

De mi az a buffer overrun, ami annyi gondot okoz napjaink- 
ban? Ha egy alkalmazás bemeneti adatot vár a külvilágból, 
azt gyakran lokális változóba, tehát a verembe (stack) teszi. 
Ha nem figyelünk oda, a beérkezett adatok olyan területeket 
is felülírhatnak, ahol már egy függvényhívás visszatérési címei 
vannak a veremben (EIP), így az adatot váró függvényünk nem 
tud visszatérni a hívójához. Megfelelő kreativitással úgy vág- 
juk felül a vermet, hogy a visszatérési cím ismét a veremre 
mutasson, ahová ismét csak saját kódokat helyezünk el, ami 
azután gyönyörűen lefut. 

Pusztán azért tudhatjuk viszonylagos biztonságban magunkat, 
mert a vírus- és féreggyártók általában minimális ismeretekkel 
(sem) rendelkeznek a megtámadott rendszerekről, és ezt a hiá- 
nyosságukat nem is óhajtják bepótolni. (Lásd a Nimdát, aki 
nem volt képes megfertőzni nem C:M-ra telepített 
oprendszereket.) 

Egy szó mint száz, a veszély valós: belső hálózatról ne publi- 
káljunk semmit. Két másik tűzfalszervezési modell terjedt el a 
gyakorlatban, melyek mindegyike figyelembe veszi ezt a ve- 
szélyt, és demilitarizált zónába (DMZ, vagy más néven 
screened network, harmadik nevén perimeter network) helye- 
zi a külvilág felé felkínált kiszolgálókat. Hogyan? Az egyik 
modell egy további tűzfalat, a másik pedig egy további alhá- 
lózatot (és IP-címeket) igényel. 


Back-to-back DMZ 


Ebben a felállásban két tűz(fa/) közé , szorulnak" a publikálan- 
dó kiszolgálók az alábbi ábrának megfelelően: 


Tűzfal Tűzfal 






SMTP-kiszolgáló 
IP-cím: 172.16.0.22 







Belső hálózat 
HE. [E]. [ 
EZ TEL EE 
IP-cím: 10.10.10.X 


2 DMZ a két tűzfal között 


Tulajdonképpen nem jogos, sőt félrevezető a back-to-back el- 
nevezés, mert a két tűzfal nem egymásnak háttal áll, hanem 
éppen hogy egyirányba , néznek". Mindegyikük a fenti ábrán 
tőle balra eső hálózatot tekinti külsőnek, a jobbra esőt pedig 
belsőnek. Tehát a DMZ a baloldali számára belső hálózat 
(benne van a LAT-ban), a jobboldali számára viszont külső 
(nincs benne a LAT-ban). 

Amire még felhívnám a figyelmet, az a DMZ-ben használt IP- 
cím. Ez bizony belső cím, akárki akármit mond is. Az SMTP- 
kiszolgáló úgy jut ki a netre, hogy a baloldali tűzfalon hagyo- 
mányos módon publikáljuk őkelmét. 

Tehát ebben a modellben a következő történt: mivel a publi- 
kált hálózat veszélyeket rejt magában, a munkaállomásokat 
egy újabb tűzfallal leválasztottuk erről a veszélyes alhálózat- 
ról. A második tűzfalon viszont már nem publikálunk semmit. 
Praktikus haszna nincs ugyan, de ilyenformán akár tucatnyi 


! 
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tűzfalat is egymás mögé állíthatunk (kisvonat mo- 
dell), köztük seregnyi DMZ-vel. 

A kialakítás egyértelmű hátránya a sok-sok plusz ká- 
belen felül az eggyel több tűzfal, bár ebből a hát- 
rányból sokan úgy kovácsolnak előnyt, hogy a két 
tűzfal különböző gyártmányú, így ha a külső el is esik, a bel- 
ső még mindig állja az ütéseket. 

Vajon hogyan lehetne a két tűzfalas megoldáshoz hasonló 
biztonságot elérni egyetlen tűzfallal? Úgy, hogy a publikálan- 
dó kiszolgálókat mégsem rakjuk be a LAT-ba. Hanem hova? 


A háromlábú ISA 


Ki mondta, hogy egy tűzfalnak csak két hálózati kártyája le- 
het? Hogy csak egy publikus hálózattal állhat kapcsolatban? 
Ez nem így van. Lehet több külső hálózattal is kapcsolata, ek- 
kor ezek között útválasztási feladatot lát el (router). Ehhez 
egyetlenegy pipát kell bepöccinteni az ISA konzolban az IP 
Packet Filters ágon: 


IP Packet Filters Properties É: 


General ] Packet Filters ] Intrusion Detection ] PPTP ] 
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At Use this page to control packet routing and packet 
ÚJ filtering properties. 





[7 Enatle Packet filtering. (Enforced by enterprise policy settings) 


[7 Enable Intrusion detection 





A Az ISA csomagtovábbító funkciójának bekapcsolása 


Tulajdonképpen nem egy valódi routert kapunk, hanem egy 
bezártat. Csak azokat a protokollokat továbbítja, és csak oda, 
amiket a Packet Filterekben megadunk. Tehát kezdetben a kö- 
vetkező csomagokat engedi át: semmit. Ez igazán bíztató! 
Most pedig oszlassunk el egy közkeletű tévedést: háromlábú 
ISA esetén a DMZ nem a belső hálózatra esik (nincs benne a 
LAT-ban)! Sőt! Egyenesen kívül kell lennie, mert ha belül len- 
ne, éppúgy fenyegetné jelenlétével a belső számítógépeket, 
mint a legelső, legegyszerűbb modellben. Az ISA Server 
ugyanis a LAT-ban szereplő (tehát belső) hálózatok között kor- 
látlan routolást végez. Korlát csak kívül van! Tehát a modell 
így fest: 


Tűzfal 







Belső hálózat 
— 
NETRE IZZÓ 


IP-cím: 10.10.10.X 


ma kö 


Internet 


Demilitarizált zóna 


E Háromlábú ISA Server esetén a DMZ publikus IP-címet 
kap, tehát kívül van! 


Ami a legfontosabb különbséget illeti (s ez egyben a modell 
legeslegnagyobb hátránya): ebben a DMZ-ben minden kiszol- 
gálónak publikus IP-címmel kell rendelkeznie, különben nem 
sútválasztódnak" hozzá a csomagok. Itt nincs NAT, sőt sem- 
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mm 


milyen címfordítás, csupán (szűrt) csomagtovábbí- 
tás. Nincs publikálás és Pubvarázsló, csak packet fil- 
terek engedélyezése-tiltása. 


Publikáljunk" SMTP-t! 


Azért tettem idézőjelbe a ,publikáljunk" szót, hogy ezzel is 
hangsúlyozzam: ez nem a megszokott Server Publishing lesz, 
csupán át kell .engedni a packet filteren az SMTP-forgalmat. 
Jobban hasonlít router konfigurálására, mint a hagyományos 
publikálásra. 

Az SMTP-levelek betalálásáról az MX-rekordok gondoskod- 
nak, de ellentétben a Server Publishinggel, itt az MX nem az 
ISA-ra, hanem közvetlenül az SMTP-kiszolgálóra mutat. Az 
ISA ,csak" egy router — egyelőre egy bezárt router. 

Most tehát egy olyan filtert kell alkotni, amely a világ bármely 
pontjáról beérkező 25-ös porti forgalmat elengedi a végállo- 
másig. Idemásolom a megfelelő filter négy lapját: 

ada EZMESEESTZETT TET 111 


energi. FíerTyos [ocsi Conoster] Remute Como] 


EKEZETES EEEN 
Genetat [der Type ] Local Computer] Remcre Conoszer] 
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És készen is vagyunk. A levelek szépen betalálnak. Csak ép- 
pen válaszolni nem tudunk, ki már nem mennek. Vajon miért? 
Mert a fenti filter nem engedélyezi az ellentétes irányú SMTP 
forgalmat, még akkor sem, ha a második fülön , Both" irányt 
választunk! Hogyhogy? Inbound -4- Outbound c5 Both? 

De nem ám! Ugyanis a packet filterek beállításának mind a 
négy füle összefügg, és értelmezése a következő: 

H ha a levél Remote gépről Local gépre tart (DMZ-be be- 
jövő levelek), akkor értelemszerűen a Local 
Computernek kopogtatnak a 25-ös portján. (Hogy mi a 
feladó portszáma? 1024 feletti random port, esetünk- 
ben érdektelen.) 

3 ha azonban Local gépről megy Remote irányban a le- 
vél, akkor pedig aR Remote Computer 25-ös portját nyi- 
togatjuk, tehát , rossz" a filterünkben a portmegadás! 
(Nem rossz, csak nem enged ki...) 

Ezt a dilemmát egyetlen filterrel fel sem lehet oldani. A három- 
lábú DMZ-ben publikációnként két filtert kell alkotnunk, mert 
egyetlen filter nem képes , lefedni" mind a kimenő, mind pe- 
dig a bejövő csomagokat. 





A fent bemutatott filteren kívül tehát kell alkotnunk egy olyat 
is, amelyben a Local és Remote füleken ugyanúgy állítunk be 
mindent, de a portok megadásánál fordítva járunk el. 

Ez azt jelenti, hogy minden ,publikálandó" szolgáltatáshoz 
két filtert kell gyártanunk? Igen is, meg nem is. Vegyük például 
a HTTP esetét. Az esetek elsöprő többségében tökéletesen ele- 
gendő a bejövő 80-as porti forgalom engedélyezése, hisz egy 
webszerver böngészni remélhetőleg nem akar. Kivéve, ha pél- 
dául System Update Services fut rajta, mert az éjszakánként 
nekilódul, és ,leböngészi" a legújabb javításokat a 
WindowsUpdate weboldalról. Ilyenkor bizony létre kell hoz- 
ni egy kiengedő HTTP-filtert is. 


A publikus DMZ összehasonlítása a többi modellel 


Ne feledjük: a háromlábú modellben routolás történik, igaz, 
packet filterekkel korlátozott módon. Ha egy filter átenged egy 
forgalmat, az változtatás nélkül megy át. (Az intrusion 
detectorok továbbra is működnek.) 

Ettől a közvetlen hozzáféréstől sokan félni szoktak, pedig vé- 

leményem szerint ez alaptalan. A LAT-os DMZ-k IP-cím fordí- 

tása semmiféle védelmet nem jelent, hiszen amit beengedünk 

a DMZ-be, azt beengedjük, bent is van. Tehát a címfordítás el- 

maradása sem növeli a kockázatot: akár routolt, akár NAT-olt 

az elérés, egy jó kis buffer overrun simán eléri a kiszolgálónkat. 

Van azonban egy lényeges hátránya a háromlábú ISA-nak, 

mégpedig a HTTP-forgalom tekintetében. 

A háromlábú ISA-modellben a HTTP protokoll kezelése némi- 

képp kínos, mert: 

1. a DMZ-be tartó HTTP-kérés nem megy át a Web Proxy 
szolgáltatáson, így sem SSL-láncolás, sem furfangos átirá- 
nyítások, sem Reverse Proxy nem valósítható meg a ,pub- 
likált" gépekre 

2. nincs tehát HTTP-forgalom ellenőrzés, mert nincs külön 
HTTP-betörésérzékelő sem. Ezt a funkciót is a Web Proxy 
látná el. 

Ezt akár ki is próbálhatjuk. Ha betelnetelünk a 80-as porton 

egy Web Publishinggel publikált kiszolgálóra, és a megjelenő 

ablakba beírunk egy random HTTP-,parancsot" (például 

, sdígkswut" :-), az nem jut el a webszerverig, mert az ISA 

Server elküld minket a pokolba. Ha viszont a harmadik lábon 

lógó ál-publikált HTTP-kiszolgálóval tesszük ugyanezt, a ké- 

rés odaér, és a webszerver küld el minket melegebb éghajlat- 
ra — nem pedig a tűzfal. 

Ez az ára az olcsó biztonságnak. Mindenki döntse el maga, 

melyiket választja: a kiszolgálók belső hálózatra helyezését 

(Web Proxy rulez!), vagy azok külső DMZ-be helyezését, ami- 

vel elkerülheti, hogy bármit is elérhetővé kelljen tenni a belső 

hálózaton. 


Fóti Marcell 

marcellfönetacademia.net 
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MCSE, MCT, MCDBA, MZ/X 


Kapcsolódó tanfolyamaink: 


2159 -ISA Server 





Biztonságos aláírás kezelő 
alkalmazás készítése D. 


Az aláírás-ellenőrző alkalmazás 


Az előző részben az aláírás kezelő alkalmazás adatai, valamint az aláírás létrehozó alkalmazás ezeket 
hasznosító komponensei, s az ezekkel szemben támasztott követelmények lettek ismertetve. Most az 
aláírás-ellenőrző alkalmazást mutatjuk be hasonlóképpen. Ezzel nagy ívű sorozatunk egyben a végé- 
re is ér. Bár nem fért bele részletesen minden, a lényeget sikerült belegyömöszölni. Aki a leírtakat ma- 
gáévá tudta tenni bátran nekivághat egy aláírás kezelő alkalmazás fejlesztésének vagy bevezetésének. 


Az ellenőrzés feltételei 


Az aláírás ellenőrzéséhez a következők szükségesek: 

mM a nyílt, aláírással ellátott üzenet; 

mM az aláírásnak a kezdeti ellenőrzéshez szükséges mini- 
mális elemeket (ES) tartalmazni kell; 

MA a megfelelő érvényességi adatoknak rendelkezésre kell 
állni, illetve elérhetőnek kell lenni; 

HM egy megbízható ellenőrző rendszer az ellenőrzés el- 
végzésére. 


Kezdeti és utólagos (rendszeres) ellenőrzés 


Az aláírás ellenőrzésének két alapvető típusát különböztet- 
jük meg: 

A kezdeti ellenőrzés egy ellenőrző által végrehajtott folya- 
mat, melyet egy aláírás létrehozása és ellenőrzőhöz juttatása 
után minél hamarabb meg kell tenni. A kezdeti ellenőrzés 
célja, hogy azok az információk megszerezhetők legyenek, 
melyek az ellenőrzőnek szükségesek és utólagos ellenőrzé- 
sekhez is alkalmassá teszik az aláírást. Ez gyakorlatilag az 
aláírás első ellenőrzését jelent, mely egy on-line tranzakciós 
rendszer esetében az aláírást követően pár másodpercen 
vagy percen belül, egy email esetében tipikusan egy-két órán 
belül következik be. Ekkor történik az aláíró tanúsítványá- 
nak, a tanúsítási lánc tanúsítványainak, a tanúsítványokhoz 
tartozó visszavonási listáknak és egyéb érvényességi adatok- 
nak a beszerzése (tipikusan az aláírótól vagy a hitelesítési 
szolgáltatótól). 

Az utólagos (rendszeres) ellenőrzés egy ellenőrző (vagy dön- 
tőbíró) által végrehajtott folyamat, melyet hosszú idővel az 
aláírás létrehozása után is végre lehet hajtani, s amelyhez 
nincs szükség több adat megszerzésére, mint amit a kezdeti 
ellenőrzés során már megszereztek. Ez alól az a helyzet csak 
a kivétel, mikor az évekkel korábban megtett aláírás biztonsá- 
ga a közeljövőben kétségessé válik (a kriptográfiai eljárások 
elöregedése miatt), és ezért további információk beszerzése is 
szükséges lehet. A kezdeti ellenőrzésnek az érvényesítési ada- 
tokat el kell tárolnia, úgy hogy azok az utólagos ellenőrzés 
számára elérhetők legyenek. 

Nem gyakori probléma, de előfordulhat, hogy a kezdeti el- 
lenőrzés túl későn következik be, s így az aláíráskor érvényes 
ellenőrzési adatok már nem hozzáférhetők. Ez jellemzően a 
visszavonási lista periodikus kibocsátásból következik be (mi- 


nél sűrűbb a kibocsátás, annál inkább előfordulhat ez), vala- 
mint abból, hogy a lejárt tanúsítványok kikerülhetnek a tanú- 
sítványtárból. Az aláírási szabályzatnak ezekre az esetekre 
megfelelő intézkedések életbe léptetésével gondolni kell. 
Aláírás idejének megállapítása 
Az aláírás idejének megállapítása a letagadhatatlanság bizto- 
sítása és az aláírás érvényességének helyes megállapítása vé- 
gett perdöntő jelentőségű. Amennyiben az aláírás időbélyeg- 
zővel vagy időjelzéssel ellátott (ES-T), 
akkor ez nem jelent problémát, ellen- 
kező esetben más módszert kell talál- 
ni aláírás idejének meghatározására. 
A kezdeti ellenőrzés során az ellenőr- 
ző élhet például azzal a feltételezés- 
sel (amennyiben a használt tranzak- 
ciós környezet működési logikája er- 
re utal, és az aláírói dokumentumból, 
az aláírásjellemzőkbóől, illetve egyéb 
adatból más nem következik), hogy 
az aláírás ideje az ellenőrzést nem 
sokkal előzte meg, s így az aláírás 
idejét behelyettesítheti az ellenőrzés 
idejével. Ennek annyi hátulütője le- 
het, hogy egy az aláírás tényleges 
időpontjában még érvényes aláírás 
zolhatja az Ellenőrzés . visszautasításra kerül, mert az aláírás 
és ellenőrzés ideje között vált az 
aláírás érvénytelenné. Az utólagos 
(rendszeres) ellenőrzés során ez a 
módszer a kezdeti ellenőrzés idejével 
alkalmazható, melyet így nyilván tárolni kell az érvényesí- 
tési adatok mellet. Ha nem áll rendelkezésre autentikus időin- 
formáció, akkor a kezdeti ellenőrzés során az ellenőrző is kér- 
het időbélyegzést az aláírásra és az érvényesítési adatokra. Ez- 
zel később igazolhatja, hogy az elfogadás során milyen ada- 
tokra támaszkodott. 


A kezdeti ellenőrzés 
során az ellenőr- 
zőnek is érdemes 
lehet időbélyegzést 
kérni az aláírásra És 
az ellenőrző adatok- 


ra. Ezzel később iga- 





eredményét. 


Egyéb idő megfontolások 

Nem csak a túl késői, hanem a túl hamar történő ellenőrzés 
is problémát jelenthet, sőt ez okoz gyakrabban gondot. Külö- 
nösen így van ez visszavonási lista használata esetén, mikor 
az aláírás idejére érvényes lista sokszor csak az aláírást és el- 
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lenőrzést követően órákkal kerül kibocsátásra. Az 
ellenőrző számára így rendelkezésére álló lista 
emiatt még nyilván nem tartalmazhatja azt a tanú- 
sítványt, melynek visszavonására az aláírást közvet- 
lenül megelőzően vagy azt követően került sor. Az 
aláírás ellenőrzési szabályzat e probléma kezelésére tartal- 
mazhat egy türelmi időt, ami az aláírás, illetve az ellenőrzés 
kezdeti időpontjától számított várakozást jelent. Az ellenőrző 
csak e várakozást követően ellenőrizheti a visszavonási álla- 
potinformációkat. Ennek a türelmi időnek a mértéke tipiku- 
san az állapotinformációk késleltetésének idejéhez igazodik. 
Visszavonási lista esetén hosszabb, OCSP esetén egy rövi- 
debb időt jelent, s garantálja, hogy az ellenőrző a türelmi idő 
leteltével a számára releváns állapotinformációkhoz fér hoz- 
zá. Így ha a tanúsítvány visszavonására az aláírást megelő- 
zően vagy közvetlenül azt követően kerül sor, garantált 
az aláírás ellenőrzés ez esetben elvárható , sikertelen" ered- 
ménye. 

Az aláírási szabályzat tartalmazhat előírást az aláírás és idő- 
bélyegzés közötti maximális időtartamra is (hiszen a két idő- 
pont között hosszabb idő is eltelhet, főleg ha az időbélyegzést 
az ellenőrző végzi). Minél hosszabb ez az idő, annál nagyobb 
a lehetőség arra, hogy a két időpont között az aláírás érvény- 
telenné válik a magánkulcs visszavonása miatt. 





Aláírás érvényesítési adatok 


Az aláírás ellenőrzése során a következő adatok kerülnek fel- 
használásra: 
A Tanúsítványok (az aláíró tanúsítványa, attribútum tanú- 
sítványa, és szolgáltatói tanúsítványok) 
A Visszavonási állapotinformációk (visszavonási listák, 
OCSP válaszok) 
A Időbélyegzők és időjelzések 


Az időbélyegzésre az idők folyamán többször is szükség lehet, 
amennyiben az előzőleg használt időbélyegző algoritmusa 
gyengévé válna. Ilyen esetben az új időbélyegző felülbélye- 
gezheti az előző időbélyegzőt, s így egymásba ágyazott idő- 
bélyegzők alakulhatnak ki. 


Az ellenőrzési folyamat eredményei 


A kezdeti és utólagos aláírás ellenőrzési folyamatoknak 
egyaránt eredménye egy kimeneti állapot. Ennek értéke kez- 
deti ellenőrzés esetén a következők valamelyike lehet: befeje- 
zetlen ellenőrzés, sikeres ellenőrzés, sikertelen ellenőrzés. 
Utólagos ellenőrzés esetén: sikeres ellenőrzés és sikertelen el- 
lenőrzés. 

A sikeres ellenőrzés azt jelenti, hogy az aláírás ellenőrzése, 
megfelelve az aláírás ellenőrzési szabályzatnak, sikeres volt. 
A sikertelen ellenőrzés azt jelenti, hogy az aláírás nem felel 
meg az aláírás ellenőrzési szabályzatnak, mert például az 
aláírás formátuma vagy a digitális aláírás értéke nem megfele- 
lő, vagy pedig az aláíró tanúsítványát visszavonták. 

A befejezetlen ellenőrzés nem jelenti azt, hogy az aláírás-el- 
lenőrzési folyamat sikertelen volna. A folyamat akkor szolgál- 
tat ilyen eredményt, ha mind az aláírás formátuma, mind a 
digitális aláírás ellenőrzése sikeres volt, de mégsem áll ren- 
delkezésre elegendő információ ahhoz, hogy az aláírási sza- 
bályzat alapján az aláírás érvényességét egyértelműen meg 
lehessen határozni. Ennek oka — többek között — lehet az, 
hogy az aláírási szabályzat szerint meg kell várni az aláírás 
időpontjára érvényes visszavonási lista közzétételét, vagy a 





tanúsítvány éppen felfüggesztett állapotban van, s meg kell 
várni, míg érvénytelen vagy újra érvényes lesz. Ekkor az 
aláírás egy későbbi időpontban való újbóli ellenőrzése kérvé- 
nyezhetővé tehető, amikor a (még szükséges) kiegészítő érvé- 
nyesítő információ már rendelkezésre fog állni. Befejezetlen 
ellenőrzés esetében az alkalmazás vagy a felhasználó számá- 
ra olyan információkat lehet hozzáférhetővé tenni, melyek 
segítségével az alkalmazás vagy a felhasználó el tudja dön- 
teni, hogy mit kezdjen a részben érvényes elektronikus 
aláírással. 

A kezdeti aláírás ellenőrzési folyamatnak a kimeneti állapoton 
kívül eredménye az érvényesítési adatok is. Az érvényesítési 
adatokat az ellenőrzőnek kell összegyűjteni, de az aláíró is 
biztosíthatja egy részüket vagy egészüket (pl. ES-X). 


Specifikus és dinamikus aláírási szabályzat ellenőrzése 


Az aláírás-ellenőrzési rendszernek az aláírás aláírási szabály- 
zatnak megfelelő ellenőrzéséhez képesnek kell lenni a sza- 
bályzat feldolgozására. Az aláírás-ellenőrzési rendszernek két 
fő típusa létezik a szerint, hogy az aláírási szabályzatot miként 
dolgozza fel. 

A Specifikus aláírási szabályzatok ellenőrzésére képes 
rendszerek: Ezek csak bizonyos (egy vagy több) a 
rendszerbe beépített aláírási szabályzat feldolgozására 
képesek. E szabályzatok tipikusan nem gépi feldolgo- 
zásra készültek, hanem olvasható formában léteznek. 
Ilyen rendszereket jóval egyszerűbb kifejleszteni, mint 
a dinamikus ellenőrzésére képes rendszereket, utóla- 
gosan azonban körülményes beilleszteni további sza- 
bályzatok ellenőrzését. Az ilyen rendszerek tanúsítását 
a támogatott aláírási szabályzatoknak megfelelően 
(azokkal összevetve és tesztelve) kell elvégezni. 

B Dinamikusan programozható aláírási szabályzatok el- 
lenőrzésére képes rendszerek: E rendszerek a megfele- 
lő módon definiált aláírási szabályzatok mindegyiké- 
nek ellenőrzésére képesek, anélkül, hogy a rendszer 
utólagos módosítást igényelne. E rugalmasság sem 
végtelen azonban, rendszerint csak egy adott definí- 
ciós rendszer (nyelve, szintaxisa, szemantikája) szerint 
működőképes, annak előre meghatározott ellenőrzési 
készletének, eljárásainak megfelelően. Ha az aláírás- 
ellenőrzési rendszer egy általa ismeretlen rendszer 
szerint definiált aláírási szabályzattal találkozik, azt 
egyáltalán nem képes feldolgozni. Ha pedig a definí- 
ciós rendszer bővül, akkor az aláírás-ellenőrzési rend- 
szer továbbfejlesztésére lehet szükség. Az ilyen rend- 
szerek tanúsítását a támogatott definíciós rendszernek 
megfelelően (annak funkciókészletével összevetve és 
tesztelve) kell elvégezni. Tipikusan több különböző 
szabályzattal és aláírással ellenőrizve a rendszer mű- 
ködését. 


Ellenőrzési rendszerek típusai 


Az aláírás ellenőrzési rendszereknek három fő típusát külön- 
böztetjük meg: 
A Emberi közreműködéssel működő rendszerek 
XA Automatikus aláírás-ellenőrző rendszerek 
A Harmadik fél által végzett ellenőrzésen alapuló rend- 
szerek 


A harmadik fél által végzett ellenőrzésen alapuló rendszerek 
esetében az alkalmazásnak az ellenőrzést végző harmadik fél 
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(pl. érvényességi szolgáltató) hitelesítéséről, és a vele való 
kommunikáció biztonságáról kell gondoskodni. 

Az automatikus aláírás-ellenőrző rendszerek emberi közre- 
működés nélkül működnek, nincs is humán interfészük. Az 
aláírás ellenőrzési eljárás eredményét és adatait rögzíteniük 
kell oly módon, hogy az később bármikor értelmezhető le- 
hessen. 

Az emberi közreműködéssel működő rendszerek esetében az 
ellenőrzések egyes részletei automatizáltak, de az emberi 
közreműködésre és jóváhagyásra a rendszer számít. Az aláb- 
biakban az ilyen rendszerek felépítését és követelményeit mu- 
tatjuk be. 


Az alkalmazás komponensei 


Az aláírás-ellenőrző alkalmazás egy ellenőrző eljárásból, va- 
lamint különböző interfészekből áll. Az egyes interfész kom- 
ponensek a következők: 

A Aláírás választó: interfész, amin keresztül az ellenőrző 
megadhatja a feldolgozandó aláírói dokumentumot, s 
amennyiben ahhoz több aláírás lett csatolva, kivá- 
laszthatja közülük az ellenőrizni kívánt aláírást. 

A Aláírói dokumentum megjelenítő: feladata, hogy az 
aláírói dokumentumot a tartalomformátumnak megfe- 
lelően (amennyiben ilyen alkalmazásra került) megje- 
lenítse. 

m Aláírási szabályzat beszerző: az aláírásban explicit 
definiált aláírási szabályzatok ellenőrző alkalmazás 
számára történő beszerzéséről gondoskodik, jellem- 
zően egy megbízható szolgáltatón keresztül. 

H Aláírási szabályzat megjelenítő: opcionális kompo- 
nens, melynek feladata, hogy az aláírási szabályzatot 
megjelenítse. 

A Aláíró adat és kimeneti állapot megjelenítő: az aláírás 
ellenőrzésének eredményeként megjeleníti az aláíró 
nevét és az ellenőrzés kimeneti állapotát. 

I Érvényesítési adat beszerző: Az aláírás kezdeti el- 
lenőrzéséhez szükséges, az aláírásban nem szereplő, 
további aláírás érvényesítési adatok beszerzéséről 
gondoskodik. 

IA Biztonsági naplózó: opcionális komponens, ami egy 
független szolgáltató rendszerébe biztonságos módon 
rögzíti az aláírás érvényesítési adatait. 

HA Hálózati interfész: komponens, amely az aláíró által 
nem biztosított aláírás érvényesítési adatok hálózati 
kapcsolaton keresztül történő beszerzéséhez szüksé- 
ges (pl. visszavonási listák, időbélyegzők). 
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Aláírás választó 

Amennyiben több aláírás lett csatolva a feldolgozandó aláírói 
dokumentumhoz, akkor az interfész ezen aláírásokat és azok 
esetleges korábbi ellenőrzésének a kimeneti állapotát (ered- 
ményét) kijelzi, s az ellenőrző számára lehetővé teszi az el- 
lenőrizni kívánt aláírás kiválasztását. 


Aláírói dokumentum megjelenítő 


Aláírói dokumentum megjelenítő az aláírt tartalomformátum- 
nak megfelelően megjeleníti az aláírói dokumentumot az el- 
lenőrző számára. A megjelenítésnek az , Azt lett aláírva, amit 
látsz" elvet kell követnie. Amennyiben a megjelenítő nem ké- 
pes az aláírói dokumentumot ilyen módon megjeleníteni, ak- 
kor azt jeleznie kell. 


Aláírási szabályzat beszerző 


Az aláírásban explicit definiált aláírási szabályzatok, valamint 
az aláírási szabályzatban hivatkozott, de rajta kívül definiált 
elemek (pl. gyökér tanúsítványok) beszerzéséről gondoskodik 
(letölti hálózaton keresztül). Explicit nem definiált aláírási sza- 
bályzatok azonosítása nem az aláírás-ellenőrző rendszer 
feladata. Külső azonosítás után azonban e komponens besze- 
rezheti az ilyen szabályzatokat is. 


Aláírási szabályzat megjelenítő 

Aláírási szabályzat megjelenítő feladata, hogy az aláírási sza- 
bályzatot, illetve annak felhasználási területét, és az aláírás- 
hoz kapcsolódó feltételeket megjelenítse az ellenőrző számá- 
ra. Kizárólag dinamikus aláírási szabályzatokat feldolgozó 
rendszerek számára nem szükséges ilyen komponens (hiszen 
a szabályzatot a rendszer automatizmusa dolgozza fel). 


Aláíró adat és kimeneti állapot megjelenítő 


Az aláírás ellenőrzésének eredményeként a komponens meg- 
jeleníti az aláíró és az aláírói tanúsítványt hitelesítő hitelesítés- 
szolgáltató nevét. Az aláíró nevét az aláíráshoz csatolt tanúsít- 
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vány egyedi nevéből veszi. Ha az aláíráshoz az 
aláíró nem csatolta a tanúsítványát, akkor először az 
aláírói tanúsítványt hitelesítő hitelesítésszolgáltató 
nevét jeleníti meg, s ha azt az ellenőrző elfogadja, 
akkor beszerzi a szolgáltatótól az aláíró tanúsít- 

ványt, s ezt követően jeleníti meg az aláíró nevét. Az aláírói 

tanúsítványt hitelesítő hitelesítésszolgáltató nevének megjele- 

nítésére mindenképp szükség van, hiszen az aláíró neve csak 

a szolgáltató szabályai szerint és annak névterében értelmez- 

hető. 

Ezen adatokon kívül az ellenőrző kérésére a következő adato- 

kat jeleníti meg (amennyiben azok rendelkezésre állnak): 

Az elektronikus aláírás időjelzése 

Az időbélyegző adatai 

Az aláírás helye 

A kötelezettségvállalás típusa 

Az aláíró kinyilvánított vagy hitelesített szerepköre 

Az aláíró tanúsítványa 


B6EB8BHBB 





A komponens az aláírási szabályzatnak megfelelően megjele- 
níti az ellenőrzési eljárás kimeneti állapotát (eredményét) is, 
ami befejezetlen ellenőrzés, sikeres ellenőrzés és sikertelen el- 
lenőrzés lehet. 


Érvényesítési adat beszerző 


Amennyiben az aláírás kezdeti ellenőrzése befejezetlen, ak- 
kor az aláírás ellenőrzéséhez szükséges további aláírás érvé- 
nyesítési adatok beszerzésére felhívja az ellenőrző figyelmét. 
Az így beszerzett adatok ellenőrzési eljárásba való bejuttatá- 
sáról és az eljárás befejezéséről (amennyiben lehetséges) a 
komponens egyúttal gondoskodik is. 

Aláírói dokumentum 


a hozzá kapcsolódó. 
több aláírással 
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E Utólagos aláírás-ellenőrző rendszer 
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Aláíró adat és kimeneti 
állapot megjelenítő 





jAláírás idejének 


meghatározása! Biztonsági napló 


! 


Általános követelmények 


Az aláírás-ellenőrző alkalmazás tervezésekor és fejlesztésekor 
számos biztonsági és funkcionális követelményt kell a szak- 
embereknek figyelembe venni. A fontosabb és érdekesebb kö- 
vetelményeket, a követelményt indokoló veszélyekkel, és né- 
hol a lehetséges megoldásokkal együtt bemutatom. A bizton- 
sági követelmények között vannak általánosak, melyek az al- 
kalmazás egészére vagy összes moduljára vonatkoznak, vala- 
mint az egyes adatokra és komponensekre specifikusak. Az ér- 


vényességi adatok ellenőrzési szabályai szintén az alkalmazás 
követelményei közé tartoznak. 

Az általános biztonsági követelmények közé sorolhatóak a kö- 
vetkezők: 

JA Az ellenőrzőnek képesnek kell lenni bármilyen az el- 
lenőrző rendszerben történt, annak működését és biz- 
tonságát befolyásoló változás észlelésére. 

Azért, hogy az ellenőrző alkalmazást a telepítést meg- 
előzően és azt követően se lehessen észrevétlenül mó- 
dosítani. 

AA Az aláírás ellenőrzésének az aláírás ellenőrzési sza- 
bályzatnak megfelelően kell történni, mind a specifi- 
kus aláírási szabályzatok ellenőrzésére képes rendsze- 
rek, mind a dinamikusan programozható aláírási sza- 
bályzatok ellenőrzésére képes rendszerek esetében. 

A A kezdeti ellenőrzés során az aláírási szabályzatnak 

megfelelően össze kell gyűjteni az aláírás érvényessé- 
gének megállapításához szükséges összes érvényesíté- 
si adatot. 
Ezek egy részét tartalmazhatja az aláírás maga (pl. ES, 
ES-C), más részükre hivatkozással élhet (pl. ES-C), vagy 
az aláírási és más szabályzatból következhet. Ez utób- 
biakat külső forrásból kell beszerezni. 


Érvényességi adatok ellenőrzési szabályai 


HA Egyértelműen meg kell határozni, hogy az aláírás pil- 
lanatában az aláíró tanúsítványa, attribútum tanúsítvá- 
nya (ha ilyen szerepel az aláírandó adatok között), és 
az ezekhez kötődő tanúsítási lánc érvényes volt-e. 
Kizárva az esetlegesen érvénytelen adatokon alapuló 
aláírásokat. 

A Be kell szerezni az aláírás érvényességét igazoló teljes 
tanúsítási láncot, és annak minden tanúsítványához 
kötődően azok visszavonási állapotinformációit 
(visszavonási listákat, OCSP válaszokat). 

A Az érvényesítési adatok aláírás, illetve ellenőrzéskori 
valódiságának igazolása végett be kell szerezni egy 
időbélyegzőt vagy időjelzést az aláírásra (és opcioná- 
lisan az érvényesítési adatokra) vonatkozóan. 

Az időbélyegzőt tartalmazhatja az aláírás maga 
(pl. ES-T), ellenkező esetben az ellenőrzőnek kell be- 
szerezni. k 

A Minősített aláírások ellenőrzésekor meg kell győződni 

arról, hogy az aláíró tanúsítványa biztonságos aláíró- 
eszközt alkalmazó minősített tanúsítvány. 
Az RFC 2459 szabvány szerint definiált Certificate 
Policies toldaléknak az ETSI 101-456 által meghatáro- 
zott OCP public 4 SSCD értékűnek kell lennie 
(0.4.0.1456.1.1). A Key Usage toldaléknak jelen kell 
lenni, Non-Repudiation bitjének beállítva, Digital 
Signature bítjének nem beállítva kell lennie. 

A Az aláírás érvényességének megállapításához fel kell 
építeni egy tanúsítási láncot az aláíró tanúsítványát ki- 
bocsátó hitelesítő egység és az aláírási szabályzat által 
elismert bizalmi pontok között. 

AA Az aláírás érvényességének megállapításához a tanúsí- 
tási lánc összes tanúsítványának (beleértve a bizalmi 
pont és a végfelhasználó tanúsítványát is) megkötéseit 
figyelembe kell venni. 

E megkötéseket a Basic Constraints, a Name 
Constraints, a Policy Constraints és a Policy Mappings 
toldalékok írják le. 


Aláírás választó komponens 


H Lehetővé kell tenni az ellenőrző számára, hogy 


megadja a feldolgozandó aláírói dokumentumot, s 
amennyiben több aláírás lett csatolva hozzá, kiválaszt- 
hassa az ellenőrizni kívánt aláírást. 

Ehhez az aláíráshoz kapcsolódó aláíró nevek (tanúsít- 
vány egyedi név) kijelzése szükséges. 





Aláírói dokumentum megjelenítő komponens 





ma Az aláírói dokumentum megjelenítőnek garantálni 


kell, hogy az ellenőrző számára egyértelmű, biztonsá- 
gos módon, az aláíró által meghatározott tartalomfor- 
mátumnak megfelelően történik az aláírói dokumen- 
tum megjelenítése. 

Ne fordulhasson elő, hogy az ellenőrző az aláírói do- 
kumentumot rosszul értelmezi, mert az nem megfelelő 
módon jelenik meg. 

Amennyiben. aláírói dokumentum megjelenítő nem 
képes az aláírói dokumentum tartalomformátumnak 
megfelelő módon történő megjelenítésére, akkor azt 
jeleznie kell az ellenőrző számára. 


Aláírási szabályzat beszerző komponens 


HA A kezdeti ellenőrzés során egyértelműen azonosítani 
kell az aláírással kapcsolatos aláírási szabályzatot, 





akár explicit (az aláírásban) vagy implicit (az aláí 
dokumentumban) történik rá hivatkozás. 

Az implicit hivatkozás feloldásához szükséges lehet 
humán közreműködés. 

Az ellenőrző számára biztonságos módon biztosítani 
kell a kérdéses aláírásra vonatkozó aláírási szabályzat 
másolatát. 

Jellemzően megbízható szolgáltatótól való letöltés ál- 
tal. 

Meg kell győződni arról, hogy az aláírási szabályzat 
valóban az adott aláíráshoz tartozik. 

Össze kell vetni az aláírásban jelzett aláírási szabályzat 
azonosítót (OID) és lenyomatot a beszerzett aláírási 
szabályzat tényleges azonosítójával és lenyomatával. 
Garantálni kell az aláírási szabályzat hitelességét és 
sértetlenségét. 

Ehhez ellenőrizni kell az aláírási szabályzaton szerep- 
lő aláírást. 

Amennyiben az aláírási szabályzat külsőleg definiált 
elemekre hivatkozik, akkor garantálni kell ezen ele- 
mek hitelességét és sértetlenségét. 


Ellenőrizni kell az elemeken szereplő aláírást, 
vagy más, hasonló biztonságot garantáló 
megoldást kell alkalmazni. 


Aláírási szabályzat megjelenítő komponens 


A Aláírási szabályzat megjelenítőnek garantálni kell, 


hogy az ellenőrző számára egyértelmű, biztonságos 
módon történik az aláírási szabályzat azonosítójának, 
felhasználási területének és egyéb az aláírásra vonat- 
kozó feltételeinek megjelenítése. 

A beavatkozás kizárására és a tartalomformátum felis- 
merésére ez esetben is szükség van. 

Amennyiben az aláírási szabályzatra implicit történik 
hivatkozás, képesnek kell lenni biztonságosan megje- 
leníteni azt a dokumentumot, mely a kérdéses aláírás- 
ra vonatkozó aláírási szabályzatra implicit hivatkozik. 
Szerződés, jogszabály vagy egyéb szabályzat lehet 
ilyen dokumentum. 


Aláíró adat és kimeneti állapot megjelenítő 


A Az aláíró adat és kimeneti állapot megjelenítőnek ga- 


rantálni kell, hogy az ellenőrző számára egyértelmű és 
biztonságos módon történik az aláíró és hitelesítésszol- 
gáltató nevének, az aláírás egyéb adatainak, valamint 
az ellenőrzés kimeneti állapotának a megjelenítése. 

A folyamatba való esetleges beavatkozások kizárásá- 
val, a névformátum helyes értelmezésével, a használt 
karakterkészlet felismerésével és kezelésével kell ezt 
megtenni. 


Érvényesítési adat beszerző komponens 


A Érvényesítési adat beszerzőnek a kezdeti ellenőrzés 


során lehetővé kell tenni az ellenőrző számára az 
aláírás ellenőrzéséhez szükséges további aláírás érvé- 
nyesítési adatok beszerzését, valamint gondoskodnia 
kell az ellenőrzés megfelelő kimeneti állapotáról. 
Ennek érdekében figyelmeztetnie kell az ellenőrzőt ar- 
ra, hogy mi hiányzik, és az esetlegesen beszerzett ada- 
tok feldolgozását lehetővé kell tennie. 





Almási János 
CIO 
Almasi-Janosadbrt.hu 
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környéke 


SOL Server 2000 adat- és tranzakciónapló-fájlok, 


adatbázis helyreállítási 


modellek, mentési stratégiák 


Az adatok rendszeres mentésének fontosságát mindenki tudja. Arról már olykor elfeledkezünk, hogy 
felmérjük, mennyi tranzakció (új adat, vagy módosítás) elvesztését tudjuk elviselni. Az SOL Server 
tranzakciónaplóját sok rendszergazda , nem szereti". Gyakori kérdés, miért nem lehet a tranzakciónap- 
lót kikapcsolni? Meglepően sok adatbázis , simple" helyreállítási modellben működik, ami a tranzak- 
ciónapló automatikus ürítésével jár. Ez (többnyire) megakadályozza, hogy a logfájl nagyra nőjön, de 
ugyanakkor lemezhiba, vagy egy véletlen táblatörlés után lehetetlenné teszi az utolsó pillanatig érvé- 


nyes helyreállítást. 


Az SOL Server 2000 (és 7.0) adatbázisok legalább egy adat- és 
legalább egy tranzakciónapló-fájlból állnak. Az első adatfájl a 
Master Data File, ezért ezt .mdíf kiterjesztéssel szokás jelölni. 
A további adatfájlok kiterjesztése szokás szerint .ndíf, a 
tranzakciónapló-, vagy logfájloké pedig .ldf. Ezek a jelölések 
csak konvenciók, használatuk nem kötelező. Az adatfájlok 
fájlcsoportokba szerveződnek. Az .mdf fájl kötelezően a 
"PRIMARY" fájlcsoportba tartozik, az .ndf fájlok különböző 
csoportokba kerülhetnek. A kisebb adatbázisok többnyire 
egyetlen .mdf és egy .Idf fájlból állnak. Nagyobb adatbázisok 
esetén gyakori több másodlagos adatfájl (.ndf) használata, de 
több tranzakciónapló-fájlra ritkán van szükség. (Kivétel: 
[0328551]) 


A tranzakciónapló szerepe 


A tranzakcióktól elvárt tulajdonságok az atomiság, konzisz- 
tencia, izoláció és tartósság; angol rövidítéssel: ACID. Az el- 
várt tranzakciótulajdonságok közül három (atomi, konzisztens 
és tartós) a tranzakciónapló segítségével valósul meg. 

A legtöbb modern adatbáziskezelőhöz hasonlóan az SOL 
Server ún. előre írt (write-ahead) naplózást végez. Minden 
adatmódosítás először a tranzakciónaplóba íródik, és csak 
ezután az adatlapra. A tranzakció érvényesítése (commit) al- 
kalmával a log mindenképpen diszkre íródik. Ettől a pillanat- 
tól kezdve a tranzakció , tartóssá" válik: ha bármilyen ok, pél- 
dául hálózat-kimaradás miatt a módosított adatlap nem íródik 
vissza a diszkre, a tranzakciónapló alapján a módosítást az 
SOL Server , előregörgeti" a legközelebbi újraindításkor. Azok 
a tranzakciók, amelyek nem zárultak le az SOL Server leállí- 
tása, illetve a hálózatkimaradás időpontjáig, visszagörgetőd- 
nek (rollback). A (0230785] cikk egy tranzakció lefolyását a 
következő, egyszerűsített modellel érzékelteti: 


BEGIN TRANSACTION 
INSERT INTO tblTest VALUES (1) 
COMMIT TRANSACTION 





BEGIN 
TRANSACTION 


INSERT INTO 
tblTest VALUES (1) 


COMMIT 
TRANSACTION 





BEGIN TRANSACTION bejegyzés írása a 
log gyorsítótárba (cache-be), legalábbis 
elméletileg. A gyakorlatban az SOL 
Server a tranzakciót csak az első adatmó- 
dosítás pillanatában tekinti megkezdett- 
nek, tehát a BEGIN TRANSACTION be- 
jegyzés is csak az INSERT megkezdésekor 
kerül a naplóba. 


s A tábla megfelelő adatlapját az SOL 
Server beolvassa az adat gyorsítótárba (ha 
még nincs ott). 

s A lapot egy ,latch" gyors szinkronizá- 
ciós zárral védi, megtiltja a diszkre írását, 
módosított (dirty) lapként jelöli meg és " 
megszerzi a megfelelő tranzakcionális zá- 
rakat. 

s Egy INSERT bejegyzés kerül a log gyor- 
sítótárba. (DELETE utasítás esetén a törölt 
sor, UPDATE esetén a módosítás előtti és 
utáni állapot is naplózódik.) 

s Az új adatsor felíródik az adatlapra. 

e A latch felszabadul. 

A log megfelelő bejegyzéseit még nem 
szükséges diszkre írni, hiszen egyelőre 
minden módosítás csak a memóriában 
történt. 


. Egy COMMIT bejegyzés készül és a 
tranzakciónaplónak a tranzakcióra vonat- 
kozó bejegyzései a diszkre íródnak. A 
tranzakció csak akkor tekinthető érvénye- 
sítettnek, ha a log megfelelő bejegyzései 
diszkre, azaz nem törlődő tárolóra íródtak. 
A módosított adatlap a gyorsítótárban 


marad. Ha ekkor következne be egy há- 
lózat-kimaradás, a tranzakciónapló alap- 
ján az SOL Server rekonstruálni tudja a 
módosításokat. 

s A tranzakcionális zárak felszabadulnak. 


CHECKPOINT A beállított , recovery interval" konfigurá- 
ciós paraméter és a módosított adatlapok 
számának függvényében az SOL Server a 
módosított adatlapokat időnként diszkre 
írja. A checkpoint megtörténte is napló- 
zódik. Így újraindításkor az SOL Server 
tudja, hogy a checkpoint bejegyzés előtt 
lezárult tranzakciók módosításai már 
mindenképpen a diszken vannak, ezeket 
nem szükséges előregörgetni, így az adat- 
bázis helyreállítása gyorsabb lesz. 





Az adatbázis checkpoint és a log 


Adatbázis checkpoint történik a CHECKPOINT parancs hatá- 
sára, az adatbázis opciók megváltoztatása miatt, az SOL 
Server leállításakor és automatikusan, ha az SOL Server úgy 
találja, túl sok módosított adatlap van a gyorsítótárban. 


A checkpoint az adatbázison a következőket hajtja végre: 


s — Bejegyzi a tranzakciónaplóba a checkpoint kezdetét és 
sok egyéb információt. 


Az egyik ilyen feljegyzett adat a Minimum LSN. Az LSN a Log 
Seguence Number rövidítése; egy növekvő sorszám, amely a 
logbejegyzéseket azonosítja. A Minimum LSN a folyamatban 
levő tranzakciók visszagörgetéséhez szükséges legelső 
logbejegyzés, vagy a legrégebbi replikálásra váró bejegyzés 
azonosítója. Pontosabban, a Minimum LSN az alábbiak közül 
a legkisebb: 

HA A checkpoint kezdetének LSN-je. 

mm A legöregebb nyitott tranzakció kezdetének LSN-je. 

ma Tranzakcionális replikáció esetén, a legrégebbi, még 

nem replikált tranzakció bejegyzés LSN-je. 


s Ha az adatbázis SIMPLE helyreállítási modellben van, 
a checkpoint törli a tranzakciónaplónak a Minimum 
LSN előtti sorait. 

e Lemezre írja a módosított adatlapokat a gyorsítótárból. 

s — Végül a checkpoint bejegyzi a tranzakciónaplóba saját 
befejezését. 


A tranzakciónaplónak a Minimum LSN-től kezdődő és a leg- 
frissebb bejegyzésig tartó részét aktívnak nevezzük. A log ak- 
tív része nem törölhető. Ha egy adatbázisban hosszan futó — 
vagy programozói hiba folytán lezáratlan — tranzakciók van- 
nak, a tranzakciónaplóból nem tudjuk eltávolítani a Minimum 
LSN utáni bejegyzéseket, vagyis a log egyre csak növekszik. 
SOL Server 2000 esetén a tranzakciónapló bejegyzéseit a nem 
dokumentált fn dblog( függvénnyel tudjuk lekérdezni. (A 
nem dokumentált parancsok, függvények, eljárások használa- 
ta általában nem javasolt, mivel verzióról verzióra megváltoz- 
hatnak, vagy megszűnhetnek. Alkalmazást nem célszerű nem 
dokumentált parancsokra építeni. Információszerzésre viszont 
használhatjuk őket.) 


Az aktuális adatbázis teljes tranzakciónaplóját a kö- 
vetkező parancs listázza ki: 


select § from ::fn dblog(NULL, NULL) s 


Az ín dblog két paramétere az a két LSN, amelyek 

közé eső bejegyzésekre kíváncsiak vagyunk. Kicsit kényelmet- 
len, hogy az előbbi lekérdezés eredménye az LSN-eket hexa- 
decimális formában jeleníti meg, de az ín dblog integer para- 
métereket vár. (Például, a "90000042:000001d3:0001" LSN-t 
"66:467:1" formában kell megadnunk.) 


A virtuális logfájlok 

A tranzakciónapló logikailag a logrekordok folyamatos soro- 
zata. Azonban a hatékonyabb logkezelés érdekében az SOL 
Server a logfájlt több virtuális logfájlra (VLF-re) bontja. A VLF- 
ek mérete és száma változó: az SOL Server dinamikusan ala- 
kítja ki őket, amikor egy adatbázist létrehozunk, vagy módo- 
sítjuk a log méretét, vagy annak mérete automatikusan meg- 
növekszik. 


Ha egy adatbázis logját nagyon kicsire méretezzük, és a log 
fájl automatikus növelésére kis lépéseket írunk elő, sok-sok 
VLF keletkezik. Ez egy idő után lassíthatja az adatbázis hely- 
reállítását. Általában jó gyakorlat a tranzakciónapló méretét 
eleve az adatfájlok méretének húsz százalékára beállítani, így 
elkerülhető a sok automatikus bővítés, ami önmagában is las- 
sulást okozhat. A húsz százalék persze nem minden esetben 
jó érték: egy nagyon nagy adatbázis esetén, ahol az adatoknak 
csak egy százaléka módosul naponta, felesleges nagy tranzak- 
ciónaplót készíteni; egy aprócska adatbázis, ahol a teljes adat- 
állomány folyamatosan módosul, esetleg nagyobb tranzakció- 
naplót igényel, mint az adatfájlok mérete. 


A virtuális logfájlokról a (nem dokumentált) dbcc loginfo pa- 
ranccsal kaphatunk információt. Például: 


dbcc loginfo("test") 


FileldjFileSízelStartfíset FSegNolStatus Parity CreateLSN 





Ft 253952 8192 9 2 64 o 
HB 253952 262144 o o o o 
3 Iz 270336 — 516096 10 2 64 9000000042 600071 
a Iz 262144 786432 11 2 64 10000000037200082 


Négy sort kaptunk, ennyi virtuális logfájlunk van. A FileSize 
oszlop mutatja a VLF méretét. A VLF-ek közül jelenleg az van 
használatban, ahol a Status oszlop tartalma 2. 


A fenti lista már sejteti, hogy az SOL Server a VLF-eket körbe 
láncolva használja. Amikor egy adatbázist létrehozunk, a fizi- 
kailag első VLF van használatban. Idővel újabb VLF-ek is el- 
használódnak a bejegyzések tárolásához. Előbb-utóbb meg- 
történik a log csonkolása is — például egy BACKUP LOG pa- 
rancs hatására. A log csonkolása mindig a Minimal LSN-ig tör- 
ténik, tehát az előtte levő terület felszabadul. A következő áb- 
ra egy olyan tranzakciónaplót mutat, ahol a harmadik VLF tar- 
talmazza a MinLSN-t és a negyedik az utolsó naplóbejegyzést. 
A szürke terület szabad. 
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] Amikor a logikai log eléri a fizikai log fájl végét, az 


E újabb bejegyzések az első szabad VLF-be kerülnek: 
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Ha a logfájl megtelik, és az automatikus bővítés opció be van 
kapcsolva, az előírt mértékben növekszik. A növekmény egy, 
vagy több új VLF-ben jelenik meg. 


A log méretének csökkentése 


Mikor lehet szükség a log méretének csökkentésére? A jellem- 
ző okok: 

A Az adatbázisunk FULL, vagy BULK LOGGED hely- 
reállítási modellben van, és rendszeresen mentjük a 
teljes adatbázist, de nem mentjük a tranzakciónaplót. 
Tévhit, hogy a teljes adatbázis mentése csonkolja a 
tranzakciónaplót. 

H Egy szokatlanul nagy (sok módosítást tartalmazó) 
tranzakció miatt a log mérete célszerűtlenül nagy lesz. 
Például, egy 100 GB-os tábla minden sorának módo- 
sítása egyetlen UPDATE utasítással kb. 200 GB 
logterületet igényel. Egy módosító utasítás akkor is 
(elemi) tranzakció, ha nem határolja BEGIN TRAN és 
COMMIT. Egy élő, lezáratlan tranzakció log bejegyzé- 
sei még SIMPLE helyreállítási modellben sem törölhe- 
tők, tehát a tranzakciónaplónk legalább 200 GB lesz. 

A Egy tranzakcionális replikációban a publikáló adatbá- 
zis tranzakciónaplója megnövekszik, mert a log reader 
valamilyen okból nem dolgozza fel a replikálandó 
tranzakciókat. (Például, nem fut az SOL Agent.) 

HA Sok, apró lépésben történő automatikus lognövekedés 
miatt túl sok (több száz) VLF keletkezik. Szeretnénk 
egy hasonló méretű, de kevesebb VLF-ből álló 
tranzakciónaplót készíteni. Ehhez először össze kell 
húznunk a logfájlt, majd egy ALTER DATABASE pa- 
ranccsal, egy lépésben megnövelni. 


A tranzakciónapló méretét a DBCC SHRINKFILE paranccsal 
csökkenthetjük. Kisméretű és csak néhány türelmes felhaszná- 
ló által használt adatbázisok esetén használható az 
AUTOSHRINK adatbázis opció, ami automatikusan összehúz- 
za az adatbázis fájlok, köztük a tranzakciónapló méretét. 
Ugyanakkor az automatikus méretcsökkentés előbb-utóbb au- 
tomatikus méretnöveléshez vezet. Az automatikus méretnöve- 
lés munkával jár, tehát lassítja az őt kiváltó tranzakció és a 
többi, éppen végrehajtás alatt álló tranzakció végrehajtását. 
Ha jó teljesítménnyel működő SOL Server alkalmazást szeret- 
nénk, legjobb elfelejteni az AUTOSHRINK opciót. 


A DBCC SHRINKFILE csak a log fizikai végén levő, üres VLF- 
eket tudja levágni. Tehát a log méretének csökkentése előtt 
célszerű a BACKUP LOG paranccsal a logot üríteni. Még ek- 
kor is előfordulhat, hogy a körbeírt log aktív része éppen a fi- 
zikailag utolsó VLF-re esik. 

Ilyen esetben, az SOL Server 7.0 esetén a DBCC SHRINKFILE 


látszólag hatástalan. Valójában az SOL Server megjegyzi a log 
összehúzására vonatkozó utasítást, és amikor a log aktív része 
elmozdul a logfájl fizikai végéről, újra megkísérli a log kívánt 
méretre csökkentését. Ha nem akarunk várni, a DBCC 
LOGINFO paranccsal megvizsgálhatjuk, hogy a log mely ré- 
szei aktívak, majd mesterségesen generált tranzakciókkal be- 
telítjük az aktuálisan használt virtuális logfájlt. Amikor egy 
másik VLF-re kerül a log aktív része, újabb BACKUP LOG 
után a DBCC SHRINKFILE eredményes lesz. 

Az SOL Server 2000 esetén a DBCC SHRINKFILE megkönnyí- 
ti a dolgunkat. Ha az általunk előírt logméretet nem tudja elér- 
ni, mert a log aktív része a fájl fizikai végén van, automatiku- 
san feltölti az aktuális VLF-et, figyelmeztet bennünket, hogy 
ürítsük (mentsük) a tranzakciónaplót. A BACKUP LOG után 
egy újabb DBCC SHRINKFILE paranccsal tovább tudjuk csök- 
kenteni a log méretét. 


A következő példa egy olyan logot mutat, amely hat, 100 MB- 
os VLF-ből áll. Jelenleg a VLF3 és a VLF4 van használatban. A 
DBCC SHRINKFILE paranccsal megadott fájlméret, a 
Target size 275MB. 
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A DBCC SHRINKFILE(LOGIKAI FÁJLNÉV, 275) parancs el- 
tünteti a fájl végén levő üres VLF-eket és a VLF4-et feltölti. 
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Egy BACKUP LOG parancs után a log aktív része valószínűleg 
a VLF1-re kerül. (Ha hosszan futó tranzakcióink vannak, elő- 
fordulhat, hogy várnunk kell, mert a lezáratlan tranzakciók 
bejegyzései nem törölhetők.) 
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Ezután egy újabb DBCC SHRINKFILE már akár 200 MB-ra is 
össze tudja húzni a log méretét. Ennél lejjebb nem tudunk 
menni, mert a log legalább két VLF-ből áll. 


Adatbázishelyreállítási modellek 


Egy SOL Server 2000 adatbázis FULL, BULK LOGGED, vagy 
SIMPLE helyreállítási (recovery) modellben lehet. (Az SOL 
Server 7.0 esetén ezek a modellek nem léteztek, illetve a 
,select into/bulkcopy" és a ,trunc. log on chkpt." adatbázis 
opciók beállításaival szabályozhattuk az adatbázisok műkö- 
dését a helyreállítás szempontjából.) 

A helyreállítási modellt a CREATE DATABASE és az ALTER 
DATABASE parancsokkal állíthatjuk be. Az alapértelmezés az 


SOL Server Enterprise és Standard változatával létrehozott 
adatbázisok esetén FULL, a Personal Edition és az MSDE adat- 
bázisai esetén pedig SIMPLE. Érdemes megjegyezni, hogy az 
adatbázis helyreállítási modellje mentés-helyreállítás, vagy le- 
kapcsolás-felkapcsolás (detach-attach) után megmarad, 
éppúgy, mint az adatbázis opciók. Tehát például, egy MSDE- 
vel fejlesztett adatbázis, amit később egy SOL Server Standard 
változaton használunk, megmarad SIMPLE modellben, amíg 
át nem állítjuk. (Hasonló meglepetés érhet bennünket az 
AUTOCLOSE adatbázisopció kapcsán.) 


SIMPLE helyreállítási modell esetén az egyszerű kezelés érde- 
kében lemondunk arról, hogy lemezhiba esetén az adatbázist 
a hiba pillanatáig helyreállítsuk. SIMPLE helyreállítási modell- 
ben levő adatbázisról készíthetünk teljes adatbázismentést, 
fájl és fájlcsoport mentéseket, differenciális mentést, de nem 
tudjuk a tranzakciónaplót menteni. A tranzakciónapló men- 
tésnek nem is lenne értelme, mivel a checkpoint automatiku- 
san törli a log inaktív részét. 

A SIMPLE modell viselkedése közelítőleg megfelel a , select 
into/bulkcopy" és a ,trunc. log on chkpt." adatbázis opciók 
bekapcsolásának az SOL Server 7.0 esetén. 


"FULL helyreállítási modellben minden adatbázisművelet telje- 
sen naplózott, még az olyan, nagy tömegű adatot érintő (bulk) 
műveletek is, mint a SELECT INTO, a CREATE INDEX és a 
BULK INSERT. 


FULL helyreállítási modellben levő adatbázis esetén menthet- 
jük a teljes adatbázist, az egyes fájlokat, vagy fájlcsoportokat 
és a tranzakciónaplót. Az adatbázisról és a fájlokról készíthe- 
tünk differenciális mentést is, amely az utolsó , rendes" men- 
tés óta bekövetkezett változásokat tartalmazza. Érdemes meg- 
jegyezni, hogy amíg az adatokról nem készítünk mentést, az 
SOL Server a tranzakciónaplót ugyanúgy automatikusan üríti, 
mint a SIMPLE modell esetén. A log mentésének csak akkor 
van értelme, ha előzőleg adatbázist, vagy adatfájlokat mentet- 
tünk. 


Egy gyakori, jól használható mentési séma a következő: 
IA Naponta mentjük az adatbázist (backup database); 
TA Óránként mentjük a tranzakciónaplót (backup log). 


Ha bármilyen ok miatt elveszik az adatbázisunk, de a tranzak- 
ciónaplót tartalmazó lemez olvasható, a logot még tudjuk 
menteni, így a hiba bekövetkeztéig tudunk helyreállítást vé- 
gezni. A tranzakciónaplót célszerű védeni a diszkhibák ellen, 
például tükrözéssel (RAIDT, vagy RAIDTO). Nem jó ötlet a 
logot RAID5-re tenni, mert lassú. 


A helyreállítás menete: 

TH Betöltjük az utolsó teljes adatbázismentést (RESTORE 
DATABASE ... WITH NORECOVERYJ]; 

H Sorra betöltjük azokat a tranzakciónapló mentéseket, 
amelyek az adatbázismentés után készültek (RESTORE 
LOG ... WITH NORECOVERY); 

mM Végül betöltjük az utoljára mentett log-ot (RESTORE 
LOG ... WITH RECOVERY). 


Természetesen, a tranzakciónapló mentések sora nem szakad- 
hat meg. Ha elveszítünk egy logmentést, nem tudjuk a követ- 
kezőt sem betölteni. Ha mentés nélkül csonkoljuk a log-ot 


(BACKUP LOG WITH TRUNCATE ONLY), akkor 
már nem is tudunk újabb logmentést készíteni, amíg 
nem végzünk egy adatbázis- vagy fájlmentést. 


Ha egy adatbázismentést veszítünk el, például sza- 

laghiba miatt, még mindig helyre tudjuk állítani az adatbázi- 
sunkat, ha megvan valamelyik régebbi adatbázismentés és az 
utána következő logmentések (megszakítás nélküli) sora. 


A BULK LOGGED modellben egyes műveletek ,gyengén" 
naplózottak. Ezeknél csak az extent (8 lapból álló egység) al- 
lokációkat naplózza az SOL Server. Gyengén naplózott műve- 
let a SELECT INTO, a bcp és a BULK INSERT, a CREATE 
INDEX és a text és image módosítások (WRITETEXT, 
UPDATETEXT). A gyengén naplózott műveletek előnye, hogy 
lényegesen gyorsabbak, mintha teljesen naplóznánk őket. 


A gyengén naplózott műveletek ellenére a BULK LOGGED 
modell megengedi a logmentéseket. Az SOL Server 
BULK LOGGED modell esetén nyilvántartja a gyengén nap- 
lózott műveletek által módosított extenteket, és ezeket a log 
mentés során szintén menti. Így a FULL modellnél leírt men- 
tési-helyreállítási séma majdnem teljesen használható 
BULK LOGGED modellben is. A kivétel a hiba bekövetkezte 
utáni logmentés. Ekkor ugyanis már nincs meg az adatbázi- 
sunk, tehát az SOL Server nem tudja a logmentés részeként a 
gyengén naplózott műveletekkel módosított extentek menté- 
sét is elvégezni. Ha ilyen műveletek történtek az utolsó 
logmentés és a hiba bekövetkezése közötti időben, nem tud- 
juk az adatbázist a hiba pillanatáig helyreállítani. 


A potenciális veszély ellenére a BULK LOGGED modell jól 
használható, és majdnem olyan biztonságos, mint a FULL mo- 
dell. A BULK LOGGED és a FULL modellek között szabadon 
kapcsolgathatunk: ugyanaz a mentési eljárás működik mind- 
két modell esetén. 


A SIMPLE modellre ez már nem igaz, mivel ott nem tudunk 
tranzakciónaplót menteni. Ha az adatbázist FULL, vagy 
BULK LOGGED modellből SIMPLE-be kapcsoljuk, a mentési 
eljárás logmentései nem futnak le. Kellemetlenebb, hogy a 
SIMPLE modellből FULL, vagy BULK LOGGED modellbe tör- 
ténő váltás után először adatmentést (adatbázis- vagy fájlmen- 
tést) kell készítenünk, és csak ezután folytatódhat a log men- 
téseket is tartalmazó mentési séma. 


Az adatbázismentés algoritmusa 


Az SOL Server 7.0 és 2000 ún. fuzzy mentési algoritmust 
használ. A fuzzy (, homályos") jelzőt azért kapta, mert az adat- 
bázis mentése során nem törődik azzal, hogy az adatlapokat 
a folyamatban levő munkák módosíthatják — tulajdonképpen 
inkonzisztens adatokat ment. Azonban a mentés végén az 
SOL Server elmenti a tranzakciónaplónak azt a részét is, 
amely a mentés ideje alatt futó tranzakciók bejegyzéseit tartal- 
mazza. Így visszatöltéskor a potenciálisan inkonzisztens adat- 
lapokat az elmentett logdarab alapján helyre lehet állítani. Ez 
ugyanaz a helyreállítási folyamat, ami az SOL Server indítása- 
kor minden adatbázisra megtörténik. A fuzzy algoritmus elő- 
nye, hogy gyors, mert az adatbázis extenteket fizikai sorrend- 
ben olvassa és nem akadályozza a futó tranzakciókat, mivel 
nem zárolja a mentett adatokat. Továbbá a mentés befejezésé- 
nek pillanatában érvényes állapotot tükröz: azok a tranzak- 
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ciók, amelyek a mentés befejezése előtt érvényesí- 
tődtek, a mentés visszatöltésekor megmaradnak, míg 


! 
! 
—] a lezáratlan tranzakciók visszagörgetődnek. 


Megjegyzés: A fentiek szerint a fuzzy backup elmen- 
ti a ttanzakciónapló egy részét is. Azonban ez nem tekinthető 
logmentésnek és nem üríti a tranzakciónaplót! A tranzakció- 
napló mentése és ürítése a BACKUP LOG paranccsal végez- 
hető. 


Az SOL Server 2000 adatbázisok mentéséről (is) sok hasznos 
információt tartalmaz a Microsoft" SOL ServerTM 2000 High 
Availability című MSPRESS könyv. A könyv 9. fejezete, amely 
a mentés helyreállítás alapjaival foglalkozik, letölthető a 
[sgiskills] címről. 


Fájl és fájlcsoport mentések 


Nagyobb adatbázisok esetén előfordulhat, hogy a teljes adat- 
bázis mentésének ideje túlságosan hosszúra nyúlik. Első pil- 
lantásra ez nem tűnik különösebben nagy problémának, mivel 
az adatbázis mentése nem blokkolja a futó tranzakciókat, és 
megfelelően gyors diszkek esetén észrevehető teljesítmény- 
csökkenést sem okoz. Azonban vannak olyan tevékenységek, 
amelyek nem történhetnek az adatbázis mentése közben: 

B Nem tudjuk menteni (és üríteni) a tranzakciónaplót, 
hiszen a fuzzy backup a tranzakciónaplóra is épít. En- 
nek következtében ha egy több óráig futó mentés köz- 
ben történik lemezmeghibásodás, csak a régebbi men- 
tésekre hagyatkozhatunk. Ettől még lehetséges az utol- 
só pillanatig érvényes helyreállítás, de minél régebbi 
mentésből indulunk ki, annál tovább tart. 

IA Nem tudjuk változtatni az adatbázis méretét. Ha meg- 
telnek az adatfájlok, vagy a logfájl, sem az autogrow, 
sem a manuális ALTER DATABASE nem segít. (Csök- 
kenteni sem tudjuk az adatfájlok méretét, de az kevés- 
sé zavaró.) 


Előrelátó tervezéssel ezek a korlátok nem okoznak gondot, de 
500 GB fölött már többnyire egyéb megoldásokra, más men- 
tési stratégiára van szükség. 


Az egyik lehetséges megoldás a split mirror (megtört tükrözé- 
sen alapuló) mentés. Egyes hardvergyártók az SOL Server 
Virtual Device Interface (VDI) for Backup specifikációra ala- 
pozva olyan megoldásokat készítenek, amellyel a több tera- 
bájtos adatbázisok mentése is csak néhány másodpercet vesz 
igénybe. Tulajdonképpen nem mentés történik, hanem a több- 
szörösen tükrözött diszkek egyik példányát leválasztják az 
SOL Serverről. A leválasztás idejére az SOL Server szünetelte- 
ti a diszkre írást, hogy a félig írt lapokat (torn page-eket) elke- 
rüljék. Ezután a leválasztott adatbázist egy másik géphez kap- 
csolhatjuk, szalagra menthetjük tetszés szerint. Elegáns, de 
költséges megoldás. 


Olcsóbb, de több szervezést igénylő megoldás az egyes fáj- 
lok, vagy fájlcsoportok mentése. Az idei, barcelonai TechEd 
konferencián a DAT335 sorszámú előadás tartalmazta a kö- 
vetkező példát. 


A példához tartozó SOL szkript letölthető az előadó, Kimberly 
L. Tripp honlapjáról [sgiskills]. Haladhatunk az 2 —— enter 
events 2 Past Events 2 Microsoft TechEd Barcelona 2 SOL 
ServerTM 2000 Tips and Tricks for DBAs and Developers 
(DAT335) 2 demo scripts útvonalon, illetve használhatjuk a 
(sglfilesave] URL-t. 
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A fenti adatbázis egy .mdf, három .lIdf és egy .log fájlból áll. 
Az első mentések sorozata tartalmaz fájlmentést (a PRIMARY 
csoportban található .mdf fájlról), tranzakciónapló mentést, 
fájlcsoport és fájlcsoport differenciális mentéseket. Észreve- 
hetjük, hogy teljes adatbázismentés soha nem készül, ennek 
ellenére a hiba pillanatáig érvényes helyreállítást tudunk vé- 
gezni. 


A helyreállítás menete a következő: 

A a tranzakciónapló végét - ez a (11) sorszámú mentés. 

A Helyreállítjuk az adatbázis szerkezetét. Ehhez betölt- 
jük az elsődleges adatbázis fájl utolsó mentését (7) és 
a fájlcsoport utolsó teljes mentését (3). 

A A gyorsabb helyreállítás érdekében betöltjük a legfris- 
sebb differenciális mentést (9). 

A Betöltjük azokat a logmentéseket, amelyek az adatbá- 
zis konzisztens állapotba hozásához szükségesek. Az 
ábra alapján valószínűleg a (8), (10) és (11) sorszámú 
mentésekre lesz szükség, de elképzelhető, hogy ko- 
rábbi log mentésekre is szükségünk lesz, ha az adatbá- 
zison hosszú tranzakciók futottak. 


Hogyan állapíthatjuk meg, meddig kell visszamenni a 
logmentések sorában? 

A RESTORE HEADERONLY SOL parancs kilistázza a men- 
tés(ek) jellemzőit, köztük a FirstLSN-t. Fájl, fájlcsoport és adat- 
bázis mentés esetén a FirstLSN az adott mentés végrehajtása 
alatt nyitott állapotú legöregebb tranzakció LSN-je. Log men- 
tés esetén a FirstLSN annak a legrégebbi tranzakciónak az 
LSN-je, amelyet az adott log mentés teljes egészében tartal- 
maz. Azzal a logmentéssel kell kezdenünk az adatbázis kon- 
zisztenssé tételét, amelynek MinLSN-je kisebb, mint korábban 
betöltött fájl mentés (7) MinLSN-je és kisebb, mint a betöltött 
legfrissebb fájlcsoport differenciális mentés (9) MinLSN-je. 


Bonyolultnak tűnik? Szerencsére, a RESTORE parancs figyel- 
meztet, ha nem elég korai logmentést akarunk visszatölteni. 
Mindenesetre, érdemes letölteni a szkripteket és kipróbálni. 


Kószó Károly 
rendszermérnök 
karolykemicrosoft.com 
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Professional 


Kedvezményes 





MCSE (rendszermérnök) képzés 
az öt kötelező vizsgához 
430.000 helyett már nettó 399.000 Ft-tól!!! 


Nagy, összetett informatikai rendszereket és hálóza- 
tokat üzemeltető szakemberek képzése, akiknek fela- 
datuk lesz Windows 2000 alapú hálózatok teljeskörű 
adminisztrálása és támogatása, informatikai infra- 
struktúrák tervezése. 


Október 27-től! 


MCSA (adminisztrátor) képzés 
a kötelező vizsgákhoz 
270.O000 Ft helyett már nettó 229.000 Ft-tól! 


A kisebb informatikai rendszereket és hálózatokat 
üzemeltető szakemberek számára ajánljuk, akiknek 
feladatuk lesz Windows 2000 alapú hálózatok telepí- 
tése, konfigurálása, adminisztrálása, karbantartása. 


Október 27-től! 


A képzéseken a Windows Server 2003-as rendszerek újdonságairól is szó esik. 
Igény esetén a sorozat után kedvezményes Windows Server 2003 átképzést is igénybe vehet! 


Microsoft .NET fejlesztői képzések 
párhuzamosan a Ctt és Visual Basic .NET programnyelveken 


Kezdő és haladó fejlesztők, programozók számára ajánlott képzések, akiknek feladatuk lesz összetett Windows 
alapú és webes alkalmazások készítése, fejlesztése. A tanfolyamok a kedvezményes Microsoft .NET fejlesztői 


képzéssorozat keretében is elérhetőek. 


Cít/VB.NET kezdő: 2003. október 13-17. 


Web Forms: 2003. december 1-5. 


SOL-ADO.NET: 2003. november 24-28. 
Windows Forms: 2004. január 22-26. 


A tanfolyamok biztosan indulnak. Csatlakozzon be Ön is! 
Minél több tanfolyamra jelentkezik, annál olcsóbban juthat hozzá! 


Válassza ki az Önnek megfelelő minősítést és képzési konstrukciót! 


Hivatalos Microsoft tanfolyamokra épülő, rugalmas beosztású, kedvezményes konst- 


gokat tartalmazó oktatási konstrukciók és csomagok. Kedvezményes lehetősé- 
gek a szabadon választható vizsgára felkészítő tanfolyamokra. 


A megadott árak a 2596-os ÁFÁ-t nem tartalmazzák. 


Microsoft 
CERTIFIED 


Technical Education 
Center SZÁMALK 








27 203-0304/3050 (Simon Ferenc) www.szamalk.hu/tisza 1115 Budapest, Etele út 68. 





NELACADEMIA A EUOGYAZMZZI 


Alapos .NET tudás t MCAD képesítés s 


Microsoft .NET fejlesztői tanfolyamcsomag több mint 30970 kedvezménnyel a NetAcademiánál! 


etel GC LG ETET e (TAT Tee gel 


Gondolom Önnek nem kell bemutatnunk miért érdemes új fejlesztések esetén a .NET technológiákra 
alapozni. Inkább bemutatjuk mi mit nyújtunk Önnek a tanulásban, mivel különböztetjük meg 
magunkat versenytársainktól. 


Mi nem kínálunk gyorsított tanfolyamokat! 





Több mint 1000 óra .NET oktatási és több száz óra szaktanácsadási tapasztalatunk alapján 
rengeteg kiegészítő, plusz információval látjuk el a hallgatókat, amelyeket lehetetlen gyorsított 
tanfolyamon átadni (még a normál ütemezéssel is nehéz). Emellett tudjuk, hogy időre van szükség a 
rengeteg új információ valódi megértéséhez, ezért a tanfolyamokat úgy szerveztük, hogy lehetőleg 
mindig legyen egy hét pihenő két témakör között. 


Mi a megértésre és a magas színvonalra helyezzük a hangsúlyt, nem a sebességre! 


A tanuláshoz részletes stratégiát dolgoztuk ki, amely a http://www.netacademia.net/training/tandotnet.aspx címen olvasható. 


És mi van a kedvezményekkel? 


Mint minden nagyobb volumenű megrendelésnél ezen csomagjainkra is jelentős kedvezményt adunk. 
Az alábbi táblázatban látható, hogy mindkét tanfolyamcsomag megrendelése esetén legalább 3090 
kedvezményt adunk. 








Milyen vizsgákat foglal magában az MCAD és MCSD minő 


Az alkalmazásfejlesztői címhez (MCAD) két kötelező és egy szabadon választott vizsgát kell letenni. A kötelező vizsgák Windows 
vagy Webalkalmazás fejlesztési ismereteket (sötétebb sorok) és Webszerviz technológiákat kérnek számon Cst vagy VB.NET 
nyelven. A választható vizsgák közül a magyarországi viszonyok között is jól hasznosítható SOL Server 2000 programozási 
vizsgát javasoljuk. Az MCSD fejlesztőmérnöki címhez Web és Windows alkalmazásfejlesztési ismeretekre is szükség van, és 
emellett egy tervezési vizsgát is le kell tenni, plusz egy választható vizsga az előbbihez hasonlóan. 
A tanfolyamok oktatója Soczó Zsolt MCSE, MCSD.NET, MCAD, MCDBA, MCT. Időpontok, részletes tematika és teszt 
vizsgakérdések online kiértékeléssel a http://www.netacademia.net/training címen találhatók. 


A következő táblázatban összegyűjtöttük az általunk javasolt képzési utakat Cft vagy VB.NET nyelvi alapokon. 























s Tanfolyam A § Listaár Következő 
Témakör Cs (VB.NET) Kapcsolódó vizsga Cft (VB.NET) [Ft1 















Webalk. fejlesztése 2310 (2310) 





70-315, 70-320 (70-305, 70-310) 


2003. 11. 03. 
MSSrOOOKN SZOOSNOZKOZ 
































































§ § z 2003. 11. 24 
Windows alk. fejlesztés 2555 (2565) 70-316 (70-306) 160,000 2003. 03. 22. 
j 2003. 11. 17. 
ADO.NET 2389 (2389) 3 Valamennyi 135 ,000 2003. 02. 23. k 
i Z00S7A12501 
WebServices 2524 (2524) 70-315, 70-320 (70-305, 70-310) 135,000 2003. 03. 01. 
§ 2004. 02. 09. 
.NET Framework 2349 (2415) Valamennyi 160,000 2003. 02. 09. 
400,000 
MCAD csomag 4 tanfolyam z16 " 590,000 
helyett 
500,000 
MCSD csomag 5 tanfolyam 750,000 
helyett 








Araink csak 4 illetve 5 tanfolyam együttes megrendelése esetén érvényesek! 
Minden tanfolyamárat 2599 AFA terhel. 


Jelentkezést faxon vagy levélben fogadunk el az alábbi címen/faxszámon: 








H-1062 Budapest, Andrássy út 62. " Tel.: -- 36 1 472 1214 Fax: 436 1 472 1215 " E-mail: info(vpnetacademia.net " http://www.netacademia.net 


